ASP.NET Core Blazor WebAssembly をセキュリティで保護する

Blazor WebAssembly アプリは、シングル ページ アプリケーション (SPA) と同じ方法でセキュリティ保護します。 ユーザーを SPA で認証する方法はいくつかありますが、最も一般的で包括的な方法は、OpenID Connect (OIDC) などの OAuth 2.0 プロトコルに基づく実装を使用することです。

認証ライブラリ

Blazor WebAssembly では、Microsoft.AspNetCore.Components.WebAssembly.Authentication ライブラリを介して OIDC を使用したアプリの認証と承認がサポートされています。 ライブラリには、ASP.NET Core バックエンドに対してシームレスに認証を行うための一連のプリミティブが用意されています。 ライブラリにより、ASP.NET Core Identity が、Duende Identity Server 上に構築された API 認可サポートと統合されます。 このライブラリは、OpenID Provider (OP) と呼ばれる OIDC をサポートするすべてのサードパーティ Identity プロバイダー (IP) に対して認証できます。

重要

Duende Software により、Duende Identity Server を実稼働で使用することのライセンス料の支払いが求められる場合があります。 詳細については、「ASP.NET Core 5.0 から 6.0 への移行」を参照してください。

Blazor WebAssembly の認証のサポートは、基になる認証プロトコルの詳細を処理するために使用される、oidc-client.js ライブラリに基づいて構築されています。

SameSite cookie の使用など、SPA を認証するためのその他のオプションも存在します。 ただし、Blazor WebAssembly のエンジニアリング設計は、Blazor WebAssembly アプリでの認証に最適なオプションとして OAuth および OIDC にも採用されています。 JSON Web トークン (JWT) に基づくトークンベースの認証は、機能とセキュリティ上の理由により、cookie ベースの認証に基づいて選択されています。

  • トークンベースのプロトコルを使用すると、トークンがすべての要求で送信されないため、攻撃対象領域が小さくなります。
  • サーバー エンドポイントでは、トークンが明示的に送信されるため、クロスサイト リクエスト フォージェリ (CSRF) に対する保護が必要ありません。 これにより、MVC または Razor ページ アプリと共に、Blazor WebAssembly アプリをホストすることができます。
  • トークンの権限は cookie よりも狭くなります。 たとえば、該当する機能が明示的に実装されていない限り、トークンを使用してユーザー アカウントを管理したり、ユーザーのパスワードを変更したりできません。
  • トークンの有効期間は短く、既定では 1 時間です。これにより、攻撃時間が制限されます。 トークンは、いつでも取り消すことができます。
  • 自己完結型の JWT は、クライアントとサーバーの認証プロセスを保証します。 たとえば、クライアントには、受信したトークンが正当であり、指定した認証プロセスの一環として出力されたことを検出して検証する手段があります。 サード パーティが認証プロセスの途中でトークンを切り替えようとすると、クライアントは切り替えられたトークンを検出して使用しないようにすることができます。
  • OAuth および OIDC を使用したトークンは、アプリが安全であることを確認するために、正しく動作しているユーザー エージェントに依存しません。
  • OAuth や OIDC などのトークンベースのプロトコルでは、同じセキュリティ特性のセットを使用して、ホストされたアプリとスタンドアロンのアプリの認証と認可を行うことができます。

重要

プリレンダリングは認証エンドポイントではサポートされていません (/authentication/ パス セグメント)。 詳細については、「ASP.NET Core Blazor WebAssembly のその他のセキュリティ シナリオ」を参照してください。

OIDC を使用した認証プロセス

Microsoft.AspNetCore.Components.WebAssembly.Authentication ライブラリには、OIDC を使用した認証と認可を実装するためのいくつかのプリミティブが用意されています。 大まかにいうと、認証は次のようにして行われます。

  • 匿名ユーザーがログイン ボタンを選択する、または [Authorize] 属性が適用されたページを要求すると、そのユーザーがアプリのログイン ページ (/authentication/login) にリダイレクトされます。
  • ログイン ページで、認証ライブラリが承認エンドポイントへのリダイレクトを準備します。 承認エンドポイントは、Blazor WebAssembly アプリの外部にあり、別のオリジンでホストすることができます。 エンドポイントは、ユーザーが認証されているかどうかを判断し、応答として 1 つ以上のトークンを発行する役割を担います。 認証ライブラリは、認証応答を受信するためのログイン コールバックを提供します。
    • ユーザーが認証されていない場合、そのユーザーは基になる認証システム (通常は ASP.NET Core Identity) にリダイレクトされます。
    • ユーザーが既に認証されている場合、承認エンドポイントは適切なトークンを生成し、ブラウザーをログイン コールバック エンドポイント (/authentication/login-callback) にリダイレクトします。
  • Blazor WebAssembly アプリでログイン コールバック エンドポイント (/authentication/login-callback) が読み込まれると、認証応答が処理されます。
    • 認証プロセスが正常に完了した場合、ユーザーは認証され、必要に応じてユーザーが要求した元の保護された URL に戻されます。
    • 何らかの理由で認証プロセスが失敗した場合、ユーザーはログイン失敗ページ (/authentication/login-failed) に送信され、エラーが表示されます。

Authentication コンポーネント

Authentication コンポーネント (Pages/Authentication.razor) はリモート認証操作を処理し、次のことをアプリに許可します。

  • 認証状態のアプリのルートを構成する。
  • 認証状態の UI コンテンツを設定する。
  • 認証状態を管理する。

ユーザーの登録やサインインなどの認証アクションは、Blazor フレームワークの RemoteAuthenticatorViewCore<TAuthenticationState> コンポーネントに渡されます。ここでは認証操作全体で状態が保持され、制御されます。

詳細と例については、「ASP.NET Core Blazor WebAssembly のその他のセキュリティ シナリオ」をご覧ください。

承認

Blazor WebAssembly アプリでは、すべてのクライアント側コードがユーザーによって変更される可能性があるため、承認チェックがバイパスされる可能性があります。 JavaScript SPA フレームワークや任意のオペレーティング システム用のネイティブ アプリを含め、すべてのクライアント側アプリのテクノロジにも同じことが当てはまります。

常に、クライアント側アプリからアクセスされるすべての API エンドポイント内のサーバー上で承認チェックを実行します。

アプリ全体での承認を要求する

次のいずれかの方法を使用して、[Authorize] 属性 (API ドキュメント) をアプリの各 Razor コンポーネントに適用します。

  • アプリのインポート ファイルで、Microsoft.AspNetCore.Authorization 名前空間の @using ディレクティブと、 属性の [Authorize]@attribute ディレクティブを追加します。

    _Imports.razor:

    @using Microsoft.AspNetCore.Authorization
    @attribute [Authorize]
    

    Authentication コンポーネントへの匿名アクセスを許可して、ID プロバイダーへのリダイレクトを許可します。 次の Razor コードを、@page ディレクティブの下の Authentication コンポーネントに追加します。

    Pages/Authentication.razor:

    @using Microsoft.AspNetCore.Components.WebAssembly.Authentication
    @attribute [AllowAnonymous]
    
  • Pages フォルダー内の各 Razor コンポーネントに属性を追加します。

Note

RequireAuthenticatedUser を持つポリシーに AuthorizationOptions.FallbackPolicy を設定することはサポートされていません

更新トークン

更新トークンは、Blazor WebAssembly アプリのクライアント側でセキュリティで保護することはできません。 そのため、更新トークンを直接使用するためにアプリに送信するべきではありません。

更新トークンは、ホストされている Blazor WebAssembly ソリューションのサーバー側アプリで、サード パーティの API にアクセスするために保持および使用することができます。 詳細については、「ASP.NET Core Blazor WebAssembly のその他のセキュリティ シナリオ」を参照してください。

ユーザーに対するクレームを確立する

アプリでは、サーバーへの Web API 呼び出しに基づくユーザーへのクレームが必要になることがよくあります。 たとえば、クレームは、アプリで承認を確立するためによく使用されます。 このようなシナリオにおいて、アプリでは、サービスにアクセスするためのアクセス トークンを要求し、そのトークンを使用してクレームに対するユーザー データを取得します。 例については、次のリソースを参照してください。

Identity Server を使用した Azure App Service on Linux

Identity Server を使用して Azure App Service on Linux にデプロイするときに、発行者を明示的に指定します。 詳細については、ASP.NET Core でのシングル ページ アプリの認証の概要ページを参照してください。

Windows 認証

Blazor WebAssembly またはその他の SPA フレームワークでは、Windows 認証を使用しないことをお勧めします。 Windows 認証の代わりにトークンベースのプロトコルを使用することをお勧めします (Active Directory フェデレーション サービス (AD FS) を使用する OIDC など)。

Windows 認証が Blazor WebAssembly またはその他の SPA フレームワークで使用されている場合、クロスサイト リクエスト フォージェリ (CSRF) トークンからアプリを保護するために追加の手段が必要になります。 cookie に当てはまるのと同じ問題が Windows 認証にも当てはまります。これに加えて、Windows 認証では、オリジン間での認証コンテキストの共有を防ぐメカニズムは提供されません。 CSRF からの追加の保護なしで Windows 認証を使用するアプリは、少なくとも組織のイントラネットに限定する必要があり、インターネットでは使用できません。

詳細については、「ASP.NET Core でのクロスサイト リクエスト フォージェリ (XSRF/CSRF) 攻撃の防止」を参照してください。

実装ガイダンス

この「概要」の記事では、特定のプロバイダーに対して Blazor WebAssembly アプリのユーザーを認証する方法について説明します。

スタンドアロン Blazor WebAssembly アプリ:

ホストされている Blazor WebAssembly アプリ:

構成に関するその他のガイダンスについては、次の記事を参照してください。

その他のリソース

認証ライブラリ

Blazor WebAssembly では、Microsoft.AspNetCore.Components.WebAssembly.Authentication ライブラリを介して OIDC を使用したアプリの認証と承認がサポートされています。 ライブラリには、ASP.NET Core バックエンドに対してシームレスに認証を行うための一連のプリミティブが用意されています。 ライブラリによって ASP.NET Core Identity が、Identity Server 上に構築された API 認可サポートと統合されます。 このライブラリは、OpenID Provider (OP) と呼ばれる OIDC をサポートするすべてのサードパーティ Identity プロバイダー (IP) に対して認証できます。

Blazor WebAssembly の認証のサポートは、基になる認証プロトコルの詳細を処理するために使用される、oidc-client.js ライブラリに基づいて構築されています。

SameSite cookie の使用など、SPA を認証するためのその他のオプションも存在します。 ただし、Blazor WebAssembly のエンジニアリング設計は、Blazor WebAssembly アプリでの認証に最適なオプションとして OAuth および OIDC にも採用されています。 JSON Web トークン (JWT) に基づくトークンベースの認証は、機能とセキュリティ上の理由により、cookie ベースの認証に基づいて選択されています。

  • トークンベースのプロトコルを使用すると、トークンがすべての要求で送信されないため、攻撃対象領域が小さくなります。
  • サーバー エンドポイントでは、トークンが明示的に送信されるため、クロスサイト リクエスト フォージェリ (CSRF) に対する保護が必要ありません。 これにより、MVC または Razor ページ アプリと共に、Blazor WebAssembly アプリをホストすることができます。
  • トークンの権限は cookie よりも狭くなります。 たとえば、該当する機能が明示的に実装されていない限り、トークンを使用してユーザー アカウントを管理したり、ユーザーのパスワードを変更したりできません。
  • トークンの有効期間は短く、既定では 1 時間です。これにより、攻撃時間が制限されます。 トークンは、いつでも取り消すことができます。
  • 自己完結型の JWT は、クライアントとサーバーの認証プロセスを保証します。 たとえば、クライアントには、受信したトークンが正当であり、指定した認証プロセスの一環として出力されたことを検出して検証する手段があります。 サード パーティが認証プロセスの途中でトークンを切り替えようとすると、クライアントは切り替えられたトークンを検出して使用しないようにすることができます。
  • OAuth および OIDC を使用したトークンは、アプリが安全であることを確認するために、正しく動作しているユーザー エージェントに依存しません。
  • OAuth や OIDC などのトークンベースのプロトコルでは、同じセキュリティ特性のセットを使用して、ホストされたアプリとスタンドアロンのアプリの認証と認可を行うことができます。

OIDC を使用した認証プロセス

Microsoft.AspNetCore.Components.WebAssembly.Authentication ライブラリには、OIDC を使用した認証と認可を実装するためのいくつかのプリミティブが用意されています。 大まかにいうと、認証は次のようにして行われます。

  • 匿名ユーザーがログイン ボタンを選択する、または [Authorize] 属性が適用されたページを要求すると、そのユーザーがアプリのログイン ページ (/authentication/login) にリダイレクトされます。
  • ログイン ページで、認証ライブラリが承認エンドポイントへのリダイレクトを準備します。 承認エンドポイントは、Blazor WebAssembly アプリの外部にあり、別のオリジンでホストすることができます。 エンドポイントは、ユーザーが認証されているかどうかを判断し、応答として 1 つ以上のトークンを発行する役割を担います。 認証ライブラリは、認証応答を受信するためのログイン コールバックを提供します。
    • ユーザーが認証されていない場合、そのユーザーは基になる認証システム (通常は ASP.NET Core Identity) にリダイレクトされます。
    • ユーザーが既に認証されている場合、承認エンドポイントは適切なトークンを生成し、ブラウザーをログイン コールバック エンドポイント (/authentication/login-callback) にリダイレクトします。
  • Blazor WebAssembly アプリでログイン コールバック エンドポイント (/authentication/login-callback) が読み込まれると、認証応答が処理されます。
    • 認証プロセスが正常に完了した場合、ユーザーは認証され、必要に応じてユーザーが要求した元の保護された URL に戻されます。
    • 何らかの理由で認証プロセスが失敗した場合、ユーザーはログイン失敗ページ (/authentication/login-failed) に送信され、エラーが表示されます。

Authentication コンポーネント

Authentication コンポーネント (Pages/Authentication.razor) はリモート認証操作を処理し、次のことをアプリに許可します。

  • 認証状態のアプリのルートを構成する。
  • 認証状態の UI コンテンツを設定する。
  • 認証状態を管理する。

ユーザーの登録やサインインなどの認証アクションは、Blazor フレームワークの RemoteAuthenticatorViewCore<TAuthenticationState> コンポーネントに渡されます。ここでは認証操作全体で状態が保持され、制御されます。

詳細と例については、「ASP.NET Core Blazor WebAssembly のその他のセキュリティ シナリオ」をご覧ください。

承認

Blazor WebAssembly アプリでは、すべてのクライアント側コードがユーザーによって変更される可能性があるため、承認チェックがバイパスされる可能性があります。 JavaScript SPA フレームワークや任意のオペレーティング システム用のネイティブ アプリを含め、すべてのクライアント側アプリのテクノロジにも同じことが当てはまります。

常に、クライアント側アプリからアクセスされるすべての API エンドポイント内のサーバー上で承認チェックを実行します。

アプリ全体での承認を要求する

次のいずれかの方法を使用して、[Authorize] 属性 (API ドキュメント) をアプリの各 Razor コンポーネントに適用します。

  • アプリのインポート ファイルで、Microsoft.AspNetCore.Authorization 名前空間の @using ディレクティブと、 属性の [Authorize]@attribute ディレクティブを追加します。

    _Imports.razor:

    @using Microsoft.AspNetCore.Authorization
    @attribute [Authorize]
    

    Authentication コンポーネントへの匿名アクセスを許可して、ID プロバイダーへのリダイレクトを許可します。 次の Razor コードを、@page ディレクティブの下の Authentication コンポーネントに追加します。

    Pages/Authentication.razor:

    @using Microsoft.AspNetCore.Components.WebAssembly.Authentication
    @attribute [AllowAnonymous]
    
  • Pages フォルダー内の各 Razor コンポーネントに属性を追加します。

Note

RequireAuthenticatedUser を持つポリシーに AuthorizationOptions.FallbackPolicy を設定することはサポートされていません

更新トークン

更新トークンは、Blazor WebAssembly アプリのクライアント側でセキュリティで保護することはできません。 そのため、更新トークンを直接使用するためにアプリに送信するべきではありません。

更新トークンは、ホストされている Blazor WebAssembly ソリューションのサーバー側アプリで、サード パーティの API にアクセスするために保持および使用することができます。 詳細については、「ASP.NET Core Blazor WebAssembly のその他のセキュリティ シナリオ」を参照してください。

ユーザーに対するクレームを確立する

アプリでは、サーバーへの Web API 呼び出しに基づくユーザーへのクレームが必要になることがよくあります。 たとえば、クレームは、アプリで承認を確立するためによく使用されます。 このようなシナリオにおいて、アプリでは、サービスにアクセスするためのアクセス トークンを要求し、そのトークンを使用してクレームに対するユーザー データを取得します。 例については、次のリソースを参照してください。

Identity Server を使用した Azure App Service on Linux

Identity Server を使用して Azure App Service on Linux にデプロイするときに、発行者を明示的に指定します。 詳細については、ASP.NET Core でのシングル ページ アプリの認証の概要ページを参照してください。

Windows 認証

Blazor WebAssembly またはその他の SPA フレームワークでは、Windows 認証を使用しないことをお勧めします。 Windows 認証の代わりにトークンベースのプロトコルを使用することをお勧めします (Active Directory フェデレーション サービス (AD FS) を使用する OIDC など)。

Windows 認証が Blazor WebAssembly またはその他の SPA フレームワークで使用されている場合、クロスサイト リクエスト フォージェリ (CSRF) トークンからアプリを保護するために追加の手段が必要になります。 cookie に当てはまるのと同じ問題が Windows 認証にも当てはまります。これに加えて、Windows 認証では、オリジン間での認証コンテキストの共有を防ぐメカニズムは提供されません。 CSRF からの追加の保護なしで Windows 認証を使用するアプリは、少なくとも組織のイントラネットに限定する必要があり、インターネットでは使用できません。

詳細については、「ASP.NET Core でのクロスサイト リクエスト フォージェリ (XSRF/CSRF) 攻撃の防止」を参照してください。

実装ガイダンス

この「概要」の記事では、特定のプロバイダーに対して Blazor WebAssembly アプリのユーザーを認証する方法について説明します。

スタンドアロン Blazor WebAssembly アプリ:

ホストされている Blazor WebAssembly アプリ:

構成に関するその他のガイダンスについては、次の記事を参照してください。

その他のリソース

認証ライブラリ

Blazor WebAssembly では、Microsoft.AspNetCore.Components.WebAssembly.Authentication ライブラリを介して OIDC を使用したアプリの認証と承認がサポートされています。 ライブラリには、ASP.NET Core バックエンドに対してシームレスに認証を行うための一連のプリミティブが用意されています。 ライブラリによって ASP.NET Core Identity が、Identity Server 上に構築された API 認可サポートと統合されます。 このライブラリは、OpenID Provider (OP) と呼ばれる OIDC をサポートするすべてのサードパーティ Identity プロバイダー (IP) に対して認証できます。

Blazor WebAssembly の認証のサポートは、基になる認証プロトコルの詳細を処理するために使用される、oidc-client.js ライブラリに基づいて構築されています。

SameSite cookie の使用など、SPA を認証するためのその他のオプションも存在します。 ただし、Blazor WebAssembly のエンジニアリング設計は、Blazor WebAssembly アプリでの認証に最適なオプションとして OAuth および OIDC にも採用されています。 JSON Web トークン (JWT) に基づくトークンベースの認証は、機能とセキュリティ上の理由により、cookie ベースの認証に基づいて選択されています。

  • トークンベースのプロトコルを使用すると、トークンがすべての要求で送信されないため、攻撃対象領域が小さくなります。
  • サーバー エンドポイントでは、トークンが明示的に送信されるため、クロスサイト リクエスト フォージェリ (CSRF) に対する保護が必要ありません。 これにより、MVC または Razor ページ アプリと共に、Blazor WebAssembly アプリをホストすることができます。
  • トークンの権限は cookie よりも狭くなります。 たとえば、該当する機能が明示的に実装されていない限り、トークンを使用してユーザー アカウントを管理したり、ユーザーのパスワードを変更したりできません。
  • トークンの有効期間は短く、既定では 1 時間です。これにより、攻撃時間が制限されます。 トークンは、いつでも取り消すことができます。
  • 自己完結型の JWT は、クライアントとサーバーの認証プロセスを保証します。 たとえば、クライアントには、受信したトークンが正当であり、指定した認証プロセスの一環として出力されたことを検出して検証する手段があります。 サード パーティが認証プロセスの途中でトークンを切り替えようとすると、クライアントは切り替えられたトークンを検出して使用しないようにすることができます。
  • OAuth および OIDC を使用したトークンは、アプリが安全であることを確認するために、正しく動作しているユーザー エージェントに依存しません。
  • OAuth や OIDC などのトークンベースのプロトコルでは、同じセキュリティ特性のセットを使用して、ホストされたアプリとスタンドアロンのアプリの認証と認可を行うことができます。

OIDC を使用した認証プロセス

Microsoft.AspNetCore.Components.WebAssembly.Authentication ライブラリには、OIDC を使用した認証と認可を実装するためのいくつかのプリミティブが用意されています。 大まかにいうと、認証は次のようにして行われます。

  • 匿名ユーザーがログイン ボタンを選択する、または [Authorize] 属性が適用されたページを要求すると、そのユーザーがアプリのログイン ページ (/authentication/login) にリダイレクトされます。
  • ログイン ページで、認証ライブラリが承認エンドポイントへのリダイレクトを準備します。 承認エンドポイントは、Blazor WebAssembly アプリの外部にあり、別のオリジンでホストすることができます。 エンドポイントは、ユーザーが認証されているかどうかを判断し、応答として 1 つ以上のトークンを発行する役割を担います。 認証ライブラリは、認証応答を受信するためのログイン コールバックを提供します。
    • ユーザーが認証されていない場合、そのユーザーは基になる認証システム (通常は ASP.NET Core Identity) にリダイレクトされます。
    • ユーザーが既に認証されている場合、承認エンドポイントは適切なトークンを生成し、ブラウザーをログイン コールバック エンドポイント (/authentication/login-callback) にリダイレクトします。
  • Blazor WebAssembly アプリでログイン コールバック エンドポイント (/authentication/login-callback) が読み込まれると、認証応答が処理されます。
    • 認証プロセスが正常に完了した場合、ユーザーは認証され、必要に応じてユーザーが要求した元の保護された URL に戻されます。
    • 何らかの理由で認証プロセスが失敗した場合、ユーザーはログイン失敗ページ (/authentication/login-failed) に送信され、エラーが表示されます。

Authentication コンポーネント

Authentication コンポーネント (Pages/Authentication.razor) はリモート認証操作を処理し、次のことをアプリに許可します。

  • 認証状態のアプリのルートを構成する。
  • 認証状態の UI コンテンツを設定する。
  • 認証状態を管理する。

ユーザーの登録やサインインなどの認証アクションは、Blazor フレームワークの RemoteAuthenticatorViewCore<TAuthenticationState> コンポーネントに渡されます。ここでは認証操作全体で状態が保持され、制御されます。

詳細と例については、「ASP.NET Core Blazor WebAssembly のその他のセキュリティ シナリオ」をご覧ください。

承認

Blazor WebAssembly アプリでは、すべてのクライアント側コードがユーザーによって変更される可能性があるため、承認チェックがバイパスされる可能性があります。 JavaScript SPA フレームワークや任意のオペレーティング システム用のネイティブ アプリを含め、すべてのクライアント側アプリのテクノロジにも同じことが当てはまります。

常に、クライアント側アプリからアクセスされるすべての API エンドポイント内のサーバー上で承認チェックを実行します。

アプリ全体での承認を要求する

次のいずれかの方法を使用して、[Authorize] 属性 (API ドキュメント) をアプリの各 Razor コンポーネントに適用します。

  • アプリのインポート ファイルで、Microsoft.AspNetCore.Authorization 名前空間の @using ディレクティブと、 属性の [Authorize]@attribute ディレクティブを追加します。

    _Imports.razor:

    @using Microsoft.AspNetCore.Authorization
    @attribute [Authorize]
    

    Authentication コンポーネントへの匿名アクセスを許可して、ID プロバイダーへのリダイレクトを許可します。 次の Razor コードを、@page ディレクティブの下の Authentication コンポーネントに追加します。

    Pages/Authentication.razor:

    @using Microsoft.AspNetCore.Components.WebAssembly.Authentication
    @attribute [AllowAnonymous]
    
  • Pages フォルダー内の各 Razor コンポーネントに属性を追加します。

Note

RequireAuthenticatedUser を持つポリシーに AuthorizationOptions.FallbackPolicy を設定することはサポートされていません

更新トークン

更新トークンは、Blazor WebAssembly アプリのクライアント側でセキュリティで保護することはできません。 そのため、更新トークンを直接使用するためにアプリに送信するべきではありません。

更新トークンは、ホストされている Blazor WebAssembly ソリューションのサーバー側アプリで、サード パーティの API にアクセスするために保持および使用することができます。 詳細については、「ASP.NET Core Blazor WebAssembly のその他のセキュリティ シナリオ」を参照してください。

ユーザーに対するクレームを確立する

アプリでは、サーバーへの Web API 呼び出しに基づくユーザーへのクレームが必要になることがよくあります。 たとえば、クレームは、アプリで承認を確立するためによく使用されます。 このようなシナリオにおいて、アプリでは、サービスにアクセスするためのアクセス トークンを要求し、そのトークンを使用してクレームに対するユーザー データを取得します。 例については、次のリソースを参照してください。

Identity Server を使用した Azure App Service on Linux

Identity Server を使用して Azure App Service on Linux にデプロイするときに、発行者を明示的に指定します。 詳細については、ASP.NET Core でのシングル ページ アプリの認証の概要ページを参照してください。

Windows 認証

Blazor WebAssembly またはその他の SPA フレームワークでは、Windows 認証を使用しないことをお勧めします。 Windows 認証の代わりにトークンベースのプロトコルを使用することをお勧めします (Active Directory フェデレーション サービス (AD FS) を使用する OIDC など)。

Windows 認証が Blazor WebAssembly またはその他の SPA フレームワークで使用されている場合、クロスサイト リクエスト フォージェリ (CSRF) トークンからアプリを保護するために追加の手段が必要になります。 cookie に当てはまるのと同じ問題が Windows 認証にも当てはまります。これに加えて、Windows 認証では、オリジン間での認証コンテキストの共有を防ぐメカニズムは提供されません。 CSRF からの追加の保護なしで Windows 認証を使用するアプリは、少なくとも組織のイントラネットに限定する必要があり、インターネットでは使用できません。

詳細については、「ASP.NET Core でのクロスサイト リクエスト フォージェリ (XSRF/CSRF) 攻撃の防止」を参照してください。

実装ガイダンス

この「概要」の記事では、特定のプロバイダーに対して Blazor WebAssembly アプリのユーザーを認証する方法について説明します。

スタンドアロン Blazor WebAssembly アプリ:

ホストされている Blazor WebAssembly アプリ:

構成のさらに詳しいガイダンスは、「ASP.NET Core Blazor WebAssembly のその他のセキュリティ シナリオ」をご覧ください。

その他のリソース