ASP.NET Core の認証の概要

作成者: Mike Rousos

認証は、ユーザーの ID を突き止めるプロセスです。 認可は、ユーザーがリソースにアクセスできるかどうかを判断するプロセスです。 ASP.NET Core では、認証は認証サービス IAuthenticationService によって処理されます。これは、認証ミドルウェアによって使用されます。 認証サービスは、登録済みの認証ハンドラーを使用して、認証関連のアクションを完了します。 認証関連のアクションの例を次に示します。

• ユーザーを認証する。
• 認証されていないユーザーが制限されたリソースにアクセスしようとしたときに応答する。

登録済みの認証ハンドラーとその構成オプションは、"スキーム" と呼ばれます。

認証方式は Program.cs に認証サービスを登録することによって指定されます。

• AddAuthentication の呼び出しの後にスキーム固有の拡張メソッド (AddJwtBearer や AddCookie など) を呼び出すことによって行います。 これらの拡張メソッドは AuthenticationBuilder.AddScheme を使用してスキームを適切な設定で登録します。
• AuthenticationBuilder.AddScheme を直接呼び出すことによって、あまり利用されなくなります。

たとえば、次のコードでは、cookie と JWT ベアラー認証スキームの認証サービスとハンドラーが登録されます。

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("CookieSettings", options));

AddAuthentication パラメーター JwtBearerDefaults.AuthenticationScheme は、特定のスキームが要求されていない場合に既定で使用されるスキームの名前です。

複数のスキームが使用される場合、認可ポリシー (または認可属性) で、ユーザーの認証時に使用する認証スキーム (複数可) を指定することができます。 上記の例では、cookie 認証スキームを使用する場合に名前を指定しています (既定では CookieAuthenticationDefaults.AuthenticationScheme ですが、AddCookie を呼び出すときに別の名前を指定することもできます)。

場合によっては、AddAuthentication の呼び出しが、他の拡張メソッドによって自動的に行われます。 たとえば、ASP.NET Core の ASP.NET Core Identity を使用する場合、AddAuthentication が内部的に呼び出されます。

認証ミドルウェアは、Program.cs で UseAuthentication を呼び出すことによって追加されます。 UseAuthentication を呼び出すと、以前に登録された認証スキームを使用するミドルウェアが登録されます。 認証されているユーザーに依存するすべてのミドルウェアの前に UseAuthentication を呼び出します。

認証の概念

認証には、アクセス許可の決定を行う認可用の ClaimsPrincipal を提供する役割があります。 正しいクレーム セットを生成する役割がある認証ハンドラーを選択するには、複数の認証スキームの手法があります。

• 認証スキーム
• 既定の認証スキーム。これについては、次の 2 つのセクションで説明します。
• HttpContext.User を直接設定します。

1 つの認証スキームしか登録されていない場合は、それが既定のスキームになります。 複数のスキームが登録されており、既定のスキームが指定されていない場合は、Authorize 属性でスキームを指定する必要があります。そうしないと、次のエラーがスローされます。

InvalidOperationException: authenticationScheme が指定されておらず、DefaultAuthenticateScheme が見つかりませんでした。 既定のスキームは、AddAuthentication(string defaultScheme) または AddAuthentication(Action<AuthenticationOptions> configureOptions) のいずれかを使用して設定できます。

DefaultScheme

1 つの認証スキームのみが登録されている場合、その 1 つの認証スキームは次のようになります。

• DefaultScheme として自動的に使用されます。
• AddAuthentication(IServiceCollection) または AddAuthenticationCore(IServiceCollection) 内に DefaultScheme を指定する必要がなくなります。

1 つの認証スキームが DefaultScheme として自動的に使用されないようにするには、AppContext.SetSwitch("Microsoft.AspNetCore.Authentication.SuppressAutoDefaultScheme") を呼び出します。

認証スキーム

認証スキームでは、正しいクレーム セットを生成する役割がある認証ハンドラーを選択できます。 詳細については、特定のスキームでの承認に関するページを参照してください。

認証スキームは、次のものに対応する名前です。

• 認証ハンドラー。
• ハンドラーの特定のインスタンスを構成するためのオプション。

スキームは、関連付けられたハンドラーの認証、チャレンジ、禁止動作を参照するためのメカニズムとして役立ちます。 たとえば、認証ポリシーでは、スキーム名を使用して、ユーザーの認証に使用する認証スキーム (またはスキーム) を指定できます。 認証を構成する場合は、既定の認証スキームを指定するのが一般的です。 リソースが特定のスキームを要求しない限り、既定のスキームが使用されます。 また、次のことも可能です。

• 認証、チャレンジ、禁止アクションに使用する別の既定のスキームを指定する。
• ポリシー スキームを使用して、複数のスキームを 1 つに結合する。

認証ハンドラー

認証ハンドラーは:

• スキームの動作を実装する型です。
• IAuthenticationHandler または AuthenticationHandler<TOptions> から派生しています。
• ユーザーを認証するための主要な役割を担います。

認証スキームの構成と受信要求コンテキストに基づき、認証ハンドラーは:

• 認証が成功した場合に、ユーザーの ID を表す AuthenticationTicket オブジェクトを構築します。
• 認証に失敗した場合は、'no result' または 'failure' を返します。
• ユーザーがリソースにアクセスしようとするときのチャレンジおよび禁止アクションの方法を用意しています。
  • アクセスが許可されていない (禁止)。
  • 認証されていない (チャレンジ)。

RemoteAuthenticationHandler<TOptions> と AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> は、リモート認証手順を必要とする認証のクラスです。 リモート認証手順が完了すると、ハンドラーはハンドラーによって設定された CallbackPath にコールバックします。 ハンドラーは、HandleRemoteAuthenticateAsync コールバック パスに渡される情報を使用して認証手順を完了します。 OAuth 2.0 と OIDC はどちらもこのパターンを使用します。 JWT と cookie は、ベアラー ヘッダーと cookie を直接使用して認証できるため、そうではありません。 この場合、リモートでホストされるプロバイダーは、

• 認証プロバイダーになります。
• たとえば、Facebook、Twitter、Google、Microsoft、およびハンドラー メカニズムを使用してユーザーの認証を処理するその他の OIDC プロバイダーがあります。

認証

認証スキームの認証アクションは、要求コンテキストに基づいてユーザーの ID を構築する役割を担います。 認証が成功したかどうかを示す AuthenticateResult を返します。成功した場合は、認証チケットに含まれるユーザーの ID です。 以下を参照してください。AuthenticateAsync 認証の例を以下に示します。

• cookie からユーザーの ID を構築する cookie 認証スキーム。
• ユーザーの ID を構築するための JWT ベアラー トークンを逆シリアル化し、検証する JWT ベアラー スキーム。

課題

認証チャレンジは、認証されていないユーザーが認証を必要とするエンドポイントを要求したときに、認可によって呼び出されます。 認証チャレンジが発行されるのは、匿名ユーザーが制限されたリソースを要求した場合や、ログイン リンクにアクセスした場合などです。 認可では、指定された認証スキームを使用してチャレンジが呼び出されます。何も指定されていない場合は、既定値が使用されます。 以下を参照してください。ChallengeAsync 認証チャレンジの例を次に示します。

• ログイン ページにユーザーをリダイレクトする cookie 認証スキーム。
• www-authenticate: bearer ヘッダーを持つ 401 結果を返す JWT ベアラースキーム。

チャレンジ アクションでは、要求されたリソースへのアクセスに使用する認証メカニズムがユーザーに通知されます。

禁止

認証されたユーザーがアクセスを許可されていないリソースにアクセスしようとすると、認可によって認証スキームの禁止アクションが呼び出されます。 以下を参照してください。ForbidAsync 認証の禁止の例を次に示します。

• アクセスが禁止されていることを示すページにユーザーをリダイレクトする cookie 認証スキーム。
• 403 結果を返す JWT ベアラースキーム。
• ユーザーがリソースへのアクセスを要求できるページにリダイレクトするカスタム認証スキーム。

禁止アクションを使用すると、ユーザーは次のことを知ることができます。

• 認証されている。
• 要求したリソースにアクセスすることは許可されていない。

チャレンジと禁止の違いについては、次のリンクを参照してください。

• 運用リソースハンドラーを使用したチャレンジと禁止。
• チャレンジと禁止の違い。

テナントごとの認証プロバイダー

ASP.NET Core には、マルチテナント認証用の組み込みソリューションは用意されていません。 お客様がこれを、組み込みの機能を使用して作成することは可能ですが、Microsoft ではマルチテナント認証用に Orchard Core、ABP Framework、または Finbuckle.MultiTenant を検討することをお勧めします。

Orchard Core とは:

• ASP.NET Core を使用して構築された、オープンソースの、モジュール形式かつマルチテナントのアプリ フレームワークです。
• そのアプリ フレームワークの上に構築されたコンテンツ管理システム (CMS) です。

テナントごとの認証プロバイダーの例については、Orchard Core のソースを参照してください。

ABP Framework では、モジュール性、マイクロサービス、ドメイン駆動設計、マルチテナントなど、さまざまなアーキテクチャ パターンがサポートされています。 GitHub 上の ABP Framework ソースを参照してください。

Finbuckle.MultiTenant:

• オープン ソース
• テナント解決を提供する
• 軽量
• データの分離を提供する
• テナントごとにアプリの動作を一意に構成する

その他のリソース

• ASP.NET Core で特定のスキームを使用して認可する
• ASP.NET Core のポリシー スキーム
• 承認によって保護されたユーザー データでの ASP.NET Core アプリの作成
• 認証されたユーザーをグローバルに要求する
• GitHub の複数の認証方式の使用に関する問題