ASP.NET Core Blazor の認証と承認

この記事では、Blazor アプリのセキュリティの構成と管理に関する ASP.NET Core のサポートについて説明します。

Blazor は、既存の ASP.NET Core 認証メカニズムを使用してユーザーの ID を特定します。 厳密なメカニズムは、Blazor アプリがどのようにホストされているか (サーバー側かクライアント側か) によって異なります。

セキュリティのシナリオは、Blazor アプリで承認コードがサーバー側で実行される場合とクライアント側で実行される場合とで異なります。 承認コードがサーバー上で実行される場合、承認チェックでは、アプリの領域とコンポーネントに対してアクセス規則を適用できます。 クライアント側で実行されるコードには改ざんの可能性があるため、クライアントで実行される承認コードを信頼してアクセス規則を無条件に適用したり、クライアント側のコンテンツの表示を制御したりすることはできません。

承認規則の適用を保証する必要がある場合は、クライアント側のコードで承認チェックを実装しないでください。 承認チェックと規則の適用をサーバー側レンダリング (SSR) のみに依存する Blazor Web App を作成します。

Razor ページの承認規則は、ルーティング可能な Razor コンポーネントには適用されません。 ルーティング不可能な Razor コンポーネントが Razor Pages アプリのページに埋め込まれている場合、ページの認可規則は、Razor コンポーネントと、ページのコンテンツの残りの部分に間接的に影響します。

Note

この記事のコード例では、null 許容参照型 (NRT) と .NET コンパイラの null 状態スタティック分析を採用しています。これは、.NET 6 以降の ASP.NET Core でサポートされています。 ASP.NET Core 5.0 以前をターゲットとする場合は、この記事の例から null 型の指定 (?) を削除します。

機密データと資格情報を安全に維持する

アプリ シークレット、接続文字列、資格情報、パスワード、個人識別番号 (PIN)、プライベート .NET/C# コード、秘密キー/トークンを、クライアント側コードに保存しないでください。このコードは常に安全ではありません。 クライアント側の Blazor コードでは、自社が制御する安全な Web API を介して、安全なサービスとデータベースにアクセスする必要があります。

テスト/ステージング環境と運用環境では、サーバー側の Blazor コードと Web API で安全な認証フローを使用して、プロジェクト コードまたは構成ファイル内に資格情報を保持しないようにする必要があります。 ローカルの開発テスト以外では、環境変数は最も安全なアプローチとは言えないため、機密データを格納するのに環境変数を使用しないことをお勧めします。 ローカルの開発テストでは、機密データの保護には Secret Manager ツールをお勧めします。 詳細については、次のリソースを参照してください。

• 安全な認証フロー (ASP.NET Core ドキュメント)
• Microsoft Azure サービスのマネージド ID (この記事)

クライアント側およびサーバー側のローカルでの開発とテストの場合は、Secret Manager ツールを使用して、機密性の高い資格情報を保護します。

Microsoft Azure サービスのマネージド ID

Microsoft Azure サービスの場合は、マネージド IDの使用をお勧めします。 マネージド ID を使用すると、アプリ コードに資格情報を保存せずに、Azure サービスに対して安全に認証することができます。 詳細については、次のリソースを参照してください。

• Azure リソースのマネージド ID とは (Microsoft Entra のドキュメント)
• Azure サービスのドキュメント
  • Azure SQL 用の Microsoft Entra でのマネージド ID
  • App Service と Azure Functions でマネージド ID を使用する方法

偽造防止のサポート

Blazor テンプレート:

• Program ファイルで AddRazorComponents が呼び出されると、偽造防止サービスが自動的に追加されます。
• Programファイルの要求処理パイプラインで UseAntiforgery を呼び出すことで偽造防止ミドルウェアを追加し、エンドポイントの偽造防止保護を必須にして、クロスサイト リクエスト フォージェリ (CSRF/XSRF) の脅威を軽減します。 UseAntiforgery は、UseHttpsRedirection の後に呼び出されます。 UseAntiforgery の呼び出しは、UseAuthentication および UseAuthorization の呼び出しがある場合、その後に配置する必要があります。

AntiforgeryToken コンポーネントは、偽造防止トークンを非表示フィールドとしてレンダリングします。このコンポーネントは、フォーム (EditForm) インスタンスに自動的に追加されます。 詳細については、「ASP.NET Core Blazor フォームの概要」をご覧ください。

AntiforgeryStateProvider サービスは、現在のセッションに関連付けられた偽造防止トークンへのアクセスを提供します。 サービスを挿入し、その GetAntiforgeryToken() メソッドを呼び出して、現在の AntiforgeryRequestToken を取得します。 詳しくは、「ASP.NET Core Blazor アプリから Web API を呼び出す」をご覧ください。

Blazor は、要求トークンをコンポーネントの状態に保存します。これにより、対話型コンポーネントが要求にアクセスできない場合でも、偽造防止トークンを使用できることが保証されます。

Note

偽造防止による軽減策が必要なのは、application/x-www-form-urlencoded、multipart/form-data、text/plain のいずれかでエンコードされたフォーム データをサーバーに送信するときだけです。その理由は、有効なフォーム enctype はこれらのみだからです。

詳細については、次のリソースを参照してください。

• ASP.NET Core でクロスサイト リクエスト フォージェリ (XSRF/CSRF) 攻撃を防止する: この記事は、このテーマに関する ASP.NET Core の主要な記事であり、サーバー側 Blazor Server、Blazor Web App のサーバー プロジェクト、Blazor と MVC/Razor Pages の統合に適用されます。
• ASP.NET Core Blazor フォームの概要: この記事の「偽造防止のサポート」セクションは、Blazor フォームでの偽造防止のサポートに関係しています。

サーバー側の Blazor の認証

サーバー側 Blazor アプリは、ASP.NET Core アプリと同じ方法でセキュリティ用に構成されています。 詳細については、「ASP.NET Core Security の概要」を参照してください。

認証のコンテキストは、アプリの起動時にだけ確立されます。つまり、アプリが最初に クライアントとの SignalR 接続を介して WebSocket に接続するときです。 認証は、cookie または他の何らかのベアラー トークンに基づいて行うことができますが、SignalR ハブを経由し、回線内で完全に管理されます。 認証コンテキストは、回線の有効期間を通して維持されます。 アプリは、ユーザーの認証状態を 30 分ごとに定期的に再検証します。

アプリでカスタム サービス用にユーザーをキャプチャしたり、ユーザーに対する更新に対応したりする必要がある場合は、ASP.NET Core のサーバー側と Blazor Web App のセキュリティに関するその他のシナリオに関する記事をご覧ください。

Blazor は、サーバーでレンダリングされる従来の Web アプリのように、すべてのページ ナビゲーションで Cookie を使用して新しい HTTP 要求を行うものとは異なります。 ナビゲーション イベントの間に認証がチェックされます。 ただし、Cookie は関係しません。 Cookie は、サーバーに対して HTTP 要求を行うときにだけ送信され、ユーザーが Blazor アプリ内を移動するときには送信されません。 ナビゲーションの間に、ユーザーの認証状態が Blazor 回線内でチェックされます。この状態は RevalidatingAuthenticationStateProvider 抽象化を使用してサーバー上でいつでも更新できます。

重要

カスタムの NavigationManager を実装してナビゲーション中に認証を検証することはお勧めしません。 ナビゲーションの間にアプリでカスタム認証状態ロジックを実行する必要がある場合は、カスタム AuthenticationStateProvider を使います。

Note

この記事のコード例では、null 許容参照型 (NRT) と .NET コンパイラの null 状態スタティック分析を採用しています。これは、.NET 6 以降の ASP.NET Core でサポートされています。 ASP.NET Core 5.0 以前をターゲットとする場合は、この記事の例から null 型の指定 (?) を削除します。

組み込みまたはカスタムの AuthenticationStateProvider サービスでは、ASP.NET Core の HttpContext.User から認証状態データが取得されます。 このようにして、認証状態は既存の ASP.NET Core 認証メカニズムと統合されます。

サーバー側認証の詳細については、「ASP.NET Core Blazor の認証と承認」をご覧ください。

共有状態

サーバー側 Blazor アプリはサーバー メモリ内に存在し、同じプロセス内で複数のアプリ セッションがホストされます。 アプリ セッションごとに、Blazor によってそれ自体の依存関係挿入コンテナー スコープで回線が開始されるため、スコープ サービスは Blazor セッションごとに一意です。

警告

特別な注意を払っていない限り、同じサーバーの共有状態のアプリがシングルトン サービスを使用することはお勧めできません。これにより、回線をまたいだユーザー状態のリークなど、セキュリティ上の脆弱性が生じる可能性があります。

ステートフル シングルトン サービスがそのために特に設計されている場合、Blazor アプリでそれを使用できます。 たとえば、メモリ キャッシュでは特定のエントリにアクセスするためのキーが必要なため、シングルトン メモリ キャッシュの使用が許容されます。 キャッシュで使われるキャッシュ キーをユーザーが制御できないとすると、キャッシュに格納されている状態が回線間でリークすることはありません。

状態管理に関する一般的なガイダンスについては、「ASP.NET Core Blazor 状態管理」をご覧ください。

サーバー側での機密データと資格情報のセキュリティ

テスト/ステージング環境と運用環境では、サーバー側の Blazor コードと Web API で安全な認証フローを使用して、プロジェクト コードまたは構成ファイル内に資格情報を保持しないようにする必要があります。 ローカルの開発テスト以外では、環境変数は最も安全なアプローチとは言えないため、機密データを格納するのに環境変数を使用しないことをお勧めします。 ローカルの開発テストでは、機密データの保護には Secret Manager ツールをお勧めします。 詳細については、次のリソースを参照してください。

• 安全な認証フロー (ASP.NET Core ドキュメント)
• Microsoft Azure サービスのマネージド ID (Blazor ドキュメント)

クライアント側およびサーバー側のローカルでの開発とテストの場合は、Secret Manager ツールを使用して、機密性の高い資格情報を保護します。

プロジェクト テンプレート

「ASP.NET Core Blazor 用のツール」のガイダンスに従って、新しいサーバー側 Blazor アプリを作成します。

Visual Studio

サーバー側アプリのテンプレートを選び、プロジェクトを構成したら、[認証の種類] でアプリの認証を選択します。

• なし (既定値): 認証なし。
• [個別のアカウント]: ASP.NET Core Identity を使用して、ユーザー アカウントがアプリ内に保存されます。

Visual Studio Code

.NET CLI コマンドを発行してサーバー側 Blazor アプリを作成して構成するときに、次のように -au|--auth オプションを使用して認証メカニズムを指定します。

-au {AUTHENTICATION}

Note

完全なコマンドについては、「ASP.NET Core Blazor 用のツール」をご覧ください。

次の表に、{AUTHENTICATION} プレースホルダーで使用できる認証値を示します。

認証メカニズム	説明
None (既定)	認証なし
Individual	ASP.NET Core Identity を使用してアプリに格納されているユーザー

詳細については、.NET Core ガイドの dotnet new コマンドを参照してください。

.NET CLI

.NET CLI コマンドを発行してサーバー側 Blazor アプリを作成して構成するときに、次のように -au|--auth オプションを使用して認証メカニズムを指定します。

-au {AUTHENTICATION}

Note

完全なコマンドについては、「ASP.NET Core Blazor 用のツール」をご覧ください。

次の表に、{AUTHENTICATION} プレースホルダーで使用できる認証値を示します。

認証メカニズム	説明
None (既定)	認証なし
Individual	ASP.NET Core Identity を使用してアプリに格納されているユーザー

詳細情報

• .NET Core ガイドの dotnet new コマンドを参照してください。

• コマンド シェルでテンプレートのヘルプ コマンドを実行します。

  dotnet new {PROJECT TEMPLATE} --help
  

  上記のコマンドでは、{PROJECT TEMPLATE} プレースホルダーがプロジェクト テンプレートです。

Blazor Identity UI (個別のアカウント)

認証オプションに [個別のアカウント] を選んだ場合、Blazor は、完全な Blazor ベースの Identity UI の生成をサポートします。

Blazor Web App テンプレートでは、SQL Server データベース用の Identity コードがスキャフォールディングされます。 コマンド ライン バージョンでは SQLite が使用され、Identity 用の SQLite データベースが含まれます。

このテンプレートの内容は以下のとおりです。

• 認証されたユーザーでの対話型サーバー側レンダリング (対話型 SSR) とクライアント側レンダリング (CSR) のシナリオがサポートされます。
• IdentityRazor コンポーネントと、ユーザーのサインインやサインアウトなどの日常的な認証タスク用の関連ロジックを追加します。Identity コンポーネントは、アカウントの確認とパスワードの回復、サードパーティ アプリを使用した多要素認証などの高度な Identity 機能もサポートします。 Identity コンポーネント自体はインタラクティビティをサポートしていない点に注意してください。
• Identity 関連のパッケージと依存関係を追加します。
• _Imports.razor 内の Identity パッケージを参照します。
• カスタム ユーザー Identity クラス (ApplicationUser) を作成します。
• EF Core データベース コンテキスト (ApplicationDbContext) を作成して登録します。
• 組み込みの Identity エンドポイントのルーティングを構成します。
• Identity 検証とビジネス ロジックを含みます。

Blazor フレームワークの Identity コンポーネントを調べるには、Blazor Web App プロジェクト テンプレート (参照ソース) 内の Account フォルダー下の Pages フォルダーと Shared フォルダーにあるコンポーネントにアクセスします。

対話型 WebAssembly レンダリング モードまたは対話型自動レンダリング モードを選んだ場合、サーバーがすべての認証要求と承認要求を処理し、Identity コンポーネントは、Blazor Web App のメイン プロジェクト内のサーバー上で静的にレンダリングします。

このフレームワークは、ユーザーの認証状態をブラウザーにフローするためのカスタム AuthenticationStateProvider を、サーバーとクライアント (.Client) の両方のプロジェクトで提供します。 サーバー プロジェクトは AddAuthenticationStateSerialization を呼び出し、クライアント プロジェクトは AddAuthenticationStateDeserialization を呼び出します。 クライアントではなくサーバーで認証を行うと、プリレンダリング中、.NET WebAssembly ランタイムが初期化される前に、アプリが認証状態にアクセスできます。 カスタムの AuthenticationStateProvider 実装では、Persistent Component State サービス (PersistentComponentState) を使用して認証状態を HTML コメントにシリアル化してから、それを WebAssembly から再び読み取って新しい AuthenticationState インスタンスを作成します。 詳細については、「Blazor Web App で認証状態を管理する」セクションをご覧ください。

対話型サーバー ソリューションの場合に限り、IdentityRevalidatingAuthenticationStateProvider (参照ソース) はサーバー側 AuthenticationStateProvider として、対話型回線が接続されてから 30 分ごとに接続済みのユーザーのセキュリティ スタンプを再検証します。

Blazor Identity は、ファクトリによって作成されたものではない DbContext インスタンスに依存します。これは、DbContext では、プロジェクト テンプレートの Identity コンポーネントがインタラクティビティをサポートせずに静的にレンダリングするのには不十分なため、意図的なものです。

Identity コンポーネントに静的 SSR を適用するのと同時に、Identity 以外のコンポーネントにグローバルな対話型レンダリング モードがどのように適用されるのかの説明については、「ASP.NET Core Blazor のレンダリング」 モード」をご覧ください。

プリレンダリングされた状態の保持の詳細については、「ASP.NET Core Razor コンポーネントのプリレンダリング」をご覧ください。

Note

通常、.NET 参照ソースへのドキュメント リンクを使用すると、リポジトリの既定のブランチが読み込まれます。このブランチは、.NET の次回リリースに向けて行われている現在の開発を表します。 特定のリリースのタグを選択するには、[Switch branches or tags](ブランチまたはタグの切り替え) ドロップダウン リストを使います。 詳細については、「ASP.NET Core ソース コードのバージョン タグを選択する方法」 (dotnet/AspNetCore.Docs #26205) を参照してください。

Blazor Web App で認証状態を管理する

このセクションは、以下を採用する Blazor Web App に適用されます。

• 個別のアカウント
• クライアント側レンダリング (CSR、WebAssembly ベースのインタラクティビティ)。

クライアント側の認証状態プロバイダーは、Blazor 内でのみ使用され、ASP.NET Core 認証システムとは統合されません。 プリレンダリング中、Blazor は、ページで定義されたメタデータを考慮し、ASP.NET Core 認証システムを使用して、ユーザーが認証済みかどうかを判断します。 ユーザーが別のページに移動するときは、クライアント側の認証プロバイダーが使用されます。 ユーザーがページを更新 (ページ全体の再読み込み) するときは、クライアント側の認証状態プロバイダーは、サーバーでの認証の判断に関与しません。 ユーザーの状態はサーバーで保持されないため、クライアント側で保持されていた認証状態は失われます。

これに対処するには、ASP.NET Core 認証システム内で認証を実行するのが最適な方法です。 クライアント側の認証状態プロバイダーは、ユーザーの認証状態の反映のみを処理します。 認証状態プロバイダーでこれを実現する方法の例は Blazor Web App プロジェクト テンプレートで実証されており、以下で説明します。

サーバー プロジェクトの Program ファイルで、AddAuthenticationStateSerialization を呼び出します。これにより、サーバー側 AuthenticationStateProvider によって返される AuthenticationState が、Persistent Component State サービス (PersistentComponentState) を使用してシリアル化されます。

builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization();

この API はがシリアル化するのは、ブラウザーでのアクセス用のサーバー側の名前とロール要求だけです。 すべての要求を含めるには、サーバー側での AddAuthenticationStateSerialization の呼び出しで SerializeAllClaims を true に設定します。

builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization(
        options => options.SerializeAllClaims = true);

クライアント (.Client) プロジェクトの Program ファイルで、AddAuthenticationStateDeserialization を呼び出します。これにより、AuthenticationStateProvider が追加されます。このとき、AuthenticationStateData と Persistent Component State サービス (PersistentComponentState) を使用して、AuthenticationState がサーバーから逆シリアル化されます。 サーバー プロジェクトに、対応する AddAuthenticationStateSerialization の呼び出しが必要です。

builder.Services.AddAuthorizationCore();
builder.Services.AddCascadingAuthenticationState();
builder.Services.AddAuthenticationStateDeserialization();

外部プロバイダーからの追加のクレームとトークン

外部プロバイダーからの追加の要求を格納するには、「ASP.NET Core で外部プロバイダーからの追加の要求とトークンを保持する」を参照してください。

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

Identity Server を使用して Azure App Service on Linux にデプロイするときに、発行者を明示的に指定します。 詳細については、「Identity を使用して SPA の Web API バックエンドを保護する」をご覧ください。

コンポーネントにスコープ設定されたサービス用の AuthenticationStateProvider を挿入する

正しく初期化されていない AuthenticationStateProvider の新しいインスタンスが作成されるため、カスタム スコープ内で AuthenticationStateProvider の解決を試みないでください。

コンポーネントをスコープにしたサービス内の AuthenticationStateProvider にアクセスするには、コンポーネントに AuthenticationStateProvider を挿入し、パラメーターとしてサービスに渡します。 この方法により、AuthenticationStateProvider の正しい初期化されたインスタンスが各ユーザー アプリ インスタンスに確実に使われます。

ExampleService.cs:

public class ExampleService
{
    public async Task<string> ExampleMethod(AuthenticationStateProvider authStateProvider)
    {
        var authState = await authStateProvider.GetAuthenticationStateAsync();
        var user = authState.User;

        if (user.Identity is not null && user.Identity.IsAuthenticated)
        {
            return $"{user.Identity.Name} is authenticated.";
        }
        else
        {
            return "The user is NOT authenticated.";
        }
    }
}

サービスをスコープとして登録します。 サーバー側 Blazor アプリでは、スコープ付きサービスの有効期間は、クライアント接続の回線の期間と同じです。

Program ファイルで次の操作を行います。

builder.Services.AddScoped<ExampleService>();

次の InjectAuthStateProvider コンポーネントでは、以下のことを行います。

• コンポーネントは OwningComponentBase を継承します。
• AuthenticationStateProvider が挿入されて、ExampleService.ExampleMethod に渡されます。
• ExampleService は、OwningComponentBase.ScopedServices と GetRequiredService を使用して解決されます。これにより、ExampleService の正しい初期化済みインスタンスが返され、ユーザーの回線の有効期間を通して維持されます。

InjectAuthStateProvider.razor:

@page "/inject-auth-state-provider"
@inherits OwningComponentBase
@inject AuthenticationStateProvider AuthenticationStateProvider

<h1>Inject <code>AuthenticationStateProvider</code> Example</h1>

<p>@message</p>

@code {
    private string? message;
    private ExampleService? ExampleService { get; set; }

    protected override async Task OnInitializedAsync()
    {
        ExampleService = ScopedServices.GetRequiredService<ExampleService>();

        message = await ExampleService.ExampleMethod(AuthenticationStateProvider);
    }
}

詳しくは、「ASP.NET Core Blazor 依存関係の挿入」で OwningComponentBase についてのガイダンスをご覧ください。

カスタムの AuthenticationStateProvider によるプリレンダリング中に未承認のコンテンツが表示される

カスタムのAuthenticationStateProvider によるプリレンダリング中に、未承認コンテンツ (AuthorizeView コンポーネント内のコンテンツなど) が表示されるのを防ぐには、以下のいずれかのアプローチを採用します。

• プリレンダリングをサポートするためにカスタムの AuthenticationStateProvider 用に IHostEnvironmentAuthenticationStateProvider を実装する: たとえば、IHostEnvironmentAuthenticationStateProvider の実装については、ServerAuthenticationStateProvider.cs (参照ソース) で、Blazor フレームワークの ServerAuthenticationStateProvider の実装を参照してください。

  Note

  通常、.NET 参照ソースへのドキュメント リンクを使用すると、リポジトリの既定のブランチが読み込まれます。このブランチは、.NET の次回リリースに向けて行われている現在の開発を表します。 特定のリリースのタグを選択するには、[Switch branches or tags](ブランチまたはタグの切り替え) ドロップダウン リストを使います。 詳細については、「ASP.NET Core ソース コードのバージョン タグを選択する方法」 (dotnet/AspNetCore.Docs #26205) を参照してください。

• プリレンダリングを無効にする: アプリのコンポーネント階層の最上位にある、ルート コンポーネントではないコンポーネントで、prerender パラメーターを false に設定して、レンダリング モードを指定します。

  Note

  App コンポーネントなどのルート コンポーネントを対話型にすることはサポートされていません。 そのため、App コンポーネントでプリレンダリングを直接無効にすることはできません。

  Blazor Web App プロジェクト テンプレートを基にしたアプリの場合、通常は、 App コンポーネント内で Routes コンポーネントが使用されている場所 (Components/App.razor) でプリレンダリングを無効にします。

  <Routes @rendermode="new InteractiveServerRenderMode(prerender: false)" />
  

  また、HeadOutlet コンポーネントのプリレンダリングを無効にします。

  <HeadOutlet @rendermode="new InteractiveServerRenderMode(prerender: false)" />
  

  Routes コンポーネント インスタンスに適用されるレンダリング モードを選択的に制御することもできます。 例については、「ASP.NET Core Blazor のレンダリング モード」をご覧ください。

• アプリが起動する前にサーバーでユーザーを認証する: このアプローチを採用するためには、Identity ベースのサインイン ページまたはビューを使用してアプリでユーザーの初期要求に応答し、ユーザーが認証されるまで Blazor エンドポイントへの要求を防ぐ必要があります。 詳細については、「承認によって保護されたユーザー データを使って ASP.NET Core アプリを作成する」をご覧ください。 認証後は、プリレンダリングされた Razor コンポーネント内の未承認のコンテンツは、ユーザーのよるそのコンテンツの表示が真に未承認である場合にのみ表示されます。

ユーザー状態の管理

名前には "state" という単語が含まれますが、AuthenticationStateProvider は "一般的なユーザーの状態" を格納するためのものではありません。 AuthenticationStateProvider は、ユーザーの認証状態 (アプリにサインイン済みであるかどうかと、サインインに使用したユーザー) をアプリに示すだけです。

認証には、Razor Pages や MVC アプリと同じ ASP.NET Core Identity 認証が使用されます。 ASP.NET Core Identity に格納されたユーザー状態は、アプリにコードを追加しなくても Blazor に流れます。 アプリの Blazor 部分で Identity の機能を有効にするには、ASP.NET Core Identity の記事とチュートリアルのガイダンスに従ってください。

ASP.NET Core Identity の外部での一般的な状態管理のガイダンスについては、「ASP.NET Core Blazor 状態管理」をご覧ください。

追加のセキュリティ抽象化

認証状態の管理には、さらに 2 つの抽象化が関与します。

• ServerAuthenticationStateProvider (参照ソース): サーバーから認証状態を取得するために Blazor フレームワークで使用される AuthenticationStateProvider。

• RevalidatingServerAuthenticationStateProvider (参照ソース): ホスト環境から認証状態を受け取って定期的に再検証するために Blazor フレームワークで使用される AuthenticationStateProvider サービスの基本クラス。

  既定の 30 分間の再検証間隔は、RevalidatingIdentityAuthenticationStateProvider (Areas/Identity/RevalidatingIdentityAuthenticationStateProvider.cs) で調整できます。 次の例では、間隔を 20 分に短縮しています。

  protected override TimeSpan RevalidationInterval => TimeSpan.FromMinutes(20);
  

Note

通常、.NET 参照ソースへのドキュメント リンクを使用すると、リポジトリの既定のブランチが読み込まれます。このブランチは、.NET の次回リリースに向けて行われている現在の開発を表します。 特定のリリースのタグを選択するには、[Switch branches or tags](ブランチまたはタグの切り替え) ドロップダウン リストを使います。 詳細については、「ASP.NET Core ソース コードのバージョン タグを選択する方法」 (dotnet/AspNetCore.Docs #26205) を参照してください。

サインアウト時の認証状態の管理

サーバー側の Blazor は、回線の有効期間中、すべてのブラウザー タブを含め、ユーザーの認証状態を保持します。 いずれかのタブでユーザーがサインアウトしたときに、すべてのブラウザー タブでユーザーをプロアクティブにサインオフするには、短い RevalidationInterval を指定して RevalidatingServerAuthenticationStateProvider (参照ソース) を実装する必要があります。

Note

通常、.NET 参照ソースへのドキュメント リンクを使用すると、リポジトリの既定のブランチが読み込まれます。このブランチは、.NET の次回リリースに向けて行われている現在の開発を表します。 特定のリリースのタグを選択するには、[Switch branches or tags](ブランチまたはタグの切り替え) ドロップダウン リストを使います。 詳細については、「ASP.NET Core ソース コードのバージョン タグを選択する方法」 (dotnet/AspNetCore.Docs #26205) を参照してください。

一時的なリダイレクト URL の有効期間

このセクションは Blazor Web App に適用されます。

RazorComponentsServiceOptions.TemporaryRedirectionUrlValidityDuration オプションを使用して、Blazor サーバー側レンダリングによって生成される一時的なリダイレクト URL 用に、ASP.NET Core のデータ保護の有効性を取得または設定します。 これらは一時的にしか使用されないため、有効期間は、クライアントで URL を受信してナビゲーションを開始するのに必要な長さであれば十分です。 ただし、サーバー間のクロック スキューを許容するのに十分な長さも必要です。 既定値は 5 分です。

次の例では、値は 7 分に延長されています。

builder.Services.AddRazorComponents(options => 
    options.TemporaryRedirectionUrlValidityDuration = 
        TimeSpan.FromMinutes(7));

クライアント側の Blazor 認証

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

以下を追加します。

• Microsoft.AspNetCore.Components.Authorization NuGet パッケージのパッケージ リファレンス。

  Note

  .NET アプリへのパッケージの追加に関するガイダンスについては、「パッケージ利用のワークフロー」 (NuGet ドキュメント) の "パッケージのインストールと管理" に関する記事を参照してください。 NuGet.org で正しいパッケージ バージョンを確認します。

• アプリの _Imports.razor ファイルに、Microsoft.AspNetCore.Components.Authorization 名前空間。

認証を処理するには、組み込みまたはカスタムの AuthenticationStateProvider サービスを使用します。

クライアント側の認証の詳細については、「ASP.NET Core Blazor WebAssembly を保護する」をご覧ください。

AuthenticationStateProvider サービス

AuthenticationStateProvider は、ユーザーの認証状態を取得するために AuthorizeView コンポーネントおよびカスケード型の認証サービスで使用される、基盤となるサービスです。

通常、AuthenticationStateProvider は直接使用しません。 この記事で後述する AuthorizeView コンポーネントまたは Task<AuthenticationState> のアプローチを使用します。 AuthenticationStateProvider を直接使用することの主な欠点は、基となる認証状態データが変更されてもコンポーネントに自動的に通知されないことです。

カスタムの AuthenticationStateProvider を実装するには、「ASP.NET Core Blazor の認証状態」をご覧ください。これには、ユーザーの認証状態の変更通知の実装に関するガイダンスが含まれています。

ユーザーの要求プリンシパル データを取得する

次の例に示すように、AuthenticationStateProvider サービスから現在のユーザーの ClaimsPrincipal データを提供できます。

ClaimsPrincipalData.razor:

@page "/claims-principal-data"
@using System.Security.Claims
@inject AuthenticationStateProvider AuthenticationStateProvider

<h1>ClaimsPrincipal Data</h1>

<button @onclick="GetClaimsPrincipalData">Get ClaimsPrincipal Data</button>

<p>@authMessage</p>

@if (claims.Any())
{
    <ul>
        @foreach (var claim in claims)
        {
            <li>@claim.Type: @claim.Value</li>
        }
    </ul>
}

<p>@surname</p>

@code {
    private string? authMessage;
    private string? surname;
    private IEnumerable<Claim> claims = Enumerable.Empty<Claim>();

    private async Task GetClaimsPrincipalData()
    {
        var authState = await AuthenticationStateProvider
            .GetAuthenticationStateAsync();
        var user = authState.User;

        if (user.Identity is not null && user.Identity.IsAuthenticated)
        {
            authMessage = $"{user.Identity.Name} is authenticated.";
            claims = user.Claims;
            surname = user.FindFirst(c => c.Type == ClaimTypes.Surname)?.Value;
        }
        else
        {
            authMessage = "The user is NOT authenticated.";
        }
    }
}

前の例の場合:

• ClaimsPrincipal.Claims は、UI での表示用にユーザーの要求 (claims) を返します。
• ユーザーの姓 (surname) を取得する行では、ユーザーの要求をフィルター処理する述語を指定して ClaimsPrincipal.FindAll を呼び出しています。

user.Identity.IsAuthenticated が true である場合、ユーザーが ClaimsPrincipal であるため、要求を列挙し、役割のメンバーシップを評価できます。

依存関係の挿入 (DI) とサービスについて詳しくは、「ASP.NET Core Blazor 依存関係の挿入」と「ASP.NET Core での依存関係の挿入」をご覧ください。 カスタムの AuthenticationStateProvider を実装する方法については、「ASP.NET Core Blazor の認証状態」をご覧ください。

認証状態をカスケード パラメーターとして公開する

ユーザーによってトリガーされたアクションを実行する場合など、認証状態データが手続き型ロジックに必要な場合は、型 Task<AuthenticationState> のカスケード パラメーターを定義して認証状態データを取得します。

CascadeAuthState.razor:

@page "/cascade-auth-state"

<h1>Cascade Auth State</h1>

<p>@authMessage</p>

@code {
    private string authMessage = "The user is NOT authenticated.";

    [CascadingParameter]
    private Task<AuthenticationState>? authenticationState { get; set; }

    protected override async Task OnInitializedAsync()
    {
        if (authenticationState is not null)
        {
            var authState = await authenticationState;
            var user = authState?.User;

            if (user?.Identity is not null && user.Identity.IsAuthenticated)
            {
                authMessage = $"{user.Identity.Name} is authenticated.";
            }
        }
    }
}

user.Identity.IsAuthenticated が true である場合、要求を列挙し、役割のメンバーシップを評価できます。

AuthorizeRouteView およびカスケード型の認証状態サービスを使用して、Task<AuthenticationState>カスケード型パラメーターを設定します。

次の例に示すように、いずれかの Blazor プロジェクト テンプレートを基にして、認証を有効にして Blazor アプリを作成する場合、アプリに AuthorizeRouteView および AddCascadingAuthenticationState の呼び出しが含まれます。 クライアント側 Blazor アプリには、必要なサービス登録も含まれています。 詳細については、「Router コンポーネントを使用して未承認コンテンツをカスタマイズする」セクションをご覧ください。

<Router ...>
    <Found ...>
        <AuthorizeRouteView RouteData="routeData" 
            DefaultLayout="typeof(Layout.MainLayout)" />
        ...
    </Found>
</Router>

Program ファイルで、カスケード型の認証状態サービスを登録します。

builder.Services.AddCascadingAuthenticationState();

クライアント側 Blazor アプリで、承認サービスを Program ファイルに追加します。

builder.Services.AddAuthorizationCore();

サーバー側 Blazor アプリでは、オプションと承認のためのサービスが既に存在するため、これ以上の手順は必要ありません。

承認

ユーザーが認証されると、ユーザーが実行できる操作を制御する "承認" 規則が適用されます。

通常、アクセスは以下の条件に基づいて許可または拒否されます。

• ユーザーが認証されている (サインインしている)。
• ユーザーに "ロール" が割り当てられている。
• ユーザーに "要求" がある。
• "ポリシー" が満たされている。

これらの各概念は、ASP.NET Core MVC または Razor Pages アプリと同じです。 ASP.NET Core のセキュリティの詳細については、ASP.NET Core のセキュリティと Identity の記事を参照してください。

AuthorizeView コンポーネント

AuthorizeView コンポーネントでは、ユーザーを承認するかどうかに応じて UI コンテンツが選択的に表示されます。 このアプローチは、ユーザーに対してデータを "表示する" だけで済み、手続き型ロジックでユーザーの ID を使用する必要がない場合に便利です。

このコンポーネントでは、型 AuthenticationState (Razor 構文の @context) の context 変数が公開されており、これを使って、サインインしたユーザーに関する情報にアクセスできます。

<AuthorizeView>
    <p>Hello, @context.User.Identity?.Name!</p>
</AuthorizeView>

Authorized パラメーターと NotAuthorized パラメーターの組み合わせでユーザーが承認されない場合に、表示用に別のコンテンツを提供することもできます。

<AuthorizeView>
    <Authorized>
        <p>Hello, @context.User.Identity?.Name!</p>
        <p><button @onclick="HandleClick">Authorized Only Button</button></p>
    </Authorized>
    <NotAuthorized>
        <p>You're not authorized.</p>
    </NotAuthorized>
</AuthorizeView>

@code {
    private void HandleClick() { ... }
}

AuthorizeView コンポーネントは、ユーザーの承認状態に基づいて要素の可視性を制御しますが、イベント ハンドラー自体にはセキュリティを適用しません。 前の例では、HandleClick メソッドは、承認済みのユーザーに表示されるボタンにのみ関連付けられていますが、他の場所からこのメソッドが呼び出されるのを妨ぐ手立てはありません。 メソッド レベルのセキュリティを確保するには、ハンドラー自体または関連する API に追加の承認ロジックを実装します。

Blazor Web App の Razor コンポーネントは、静的なサーバー側レンダリング (静的 SSR) 中にサーバー側で承認が失敗した場合に、<NotAuthorized> コンテンツを表示しません。 サーバー側 ASP.NET Core パイプラインは、サーバー上で承認を処理します。 未承認の要求については、サーバー側の手法を使用して処理します。 詳細については、「ASP.NET Core Blazor のレンダリング モード」をご覧ください。

警告

AuthorizeView に関連付けられたクライアント側のマークアップとメソッドは、クライアント側 Blazor アプリにレンダリングされる UI での表示と実行についてのみ保護されています。 クライアント側 Blazor アプリで承認済みのコンテンツと安全なメソッドを保護するために、コンテンツは通常、サーバー API に対する安全な承認済み Web API 呼び出しによって提供され、アプリに保存されることはありません。 詳細については、ASP.NET Core Blazor アプリから Web API を呼び出す方法の記事と「ASP.NET Core Blazor WebAssembly のセキュリティに関するその他のシナリオ」を参照してください。

Authorized と NotAuthorized のコンテンツには、他の対話型コンポーネントなど、任意の項目を含めることができます。

UI オプションまたはアクセスを制御するロールやポリシーなどの承認条件については、「承認」セクションを参照してください。

認可条件が指定されていない場合、AuthorizeView では既定のポリシーが使われます。

• 認証された (サインインした) ユーザーが認可されます。
• 認証されていない (サインアウトした) ユーザーは認可されません。

AuthorizeView コンポーネントは、NavMenu コンポーネント (Shared/NavMenu.razor) で NavLink コンポーネント (NavLink) を表示するために使用できますが、このアプローチでは、レンダリングされた出力からリスト項目が削除されるだけであることに注意してください。 ユーザーがコンポーネントに移動するのを防ぐことはできません。 宛先コンポーネントで認可を個別に実装します。

ロールベースとリソースベースの承認

AuthorizeView コンポーネントは、"ロールベース" または "ポリシーベース" の承認をサポートしています。

ロールベースの承認の場合は、Roles パラメーターを使用します。 次の例では、ユーザーには Admin または Superuser ロールのいずれかのロール要求が必要です。

<AuthorizeView Roles="Admin, Superuser">
    <p>You have an 'Admin' or 'Superuser' role claim.</p>
</AuthorizeView>

ユーザーが Admin と Superuser の両方のロール要求を持つことを必須にするには、AuthorizeView コンポーネントを入れ子にします。

<AuthorizeView Roles="Admin">
    <p>User: @context.User</p>
    <p>You have the 'Admin' role claim.</p>
    <AuthorizeView Roles="Superuser" Context="innerContext">
        <p>User: @innerContext.User</p>
        <p>You have both 'Admin' and 'Superuser' role claims.</p>
    </AuthorizeView>
</AuthorizeView>

上記のコードは、AuthenticationState コンテキストの競合を防ぐため、内部 AuthorizeView コンポーネントに対する Context を確立します。 AuthenticationState コンテキストは、コンテキストにアクセスするための標準的なアプローチ (@context.User) を使用して、外部 AuthorizeView でアクセスされます。 コンテキストは、名前付き innerContext コンテキスト (@innerContext.User) を使用して、内部 AuthorizeView でアクセスされます。

構成ガイダンスなどの詳細については、「ASP.NET Core でのロールベースの認可」を参照してください。

ポリシーベースの承認の場合、単一のポリシー名で Policy パラメーターを使用します。

<AuthorizeView Policy="Over21">
    <p>You satisfy the 'Over21' policy.</p>
</AuthorizeView>

ユーザーが複数のポリシーのいずれかを満たす必要がある場合に対応するには、ユーザーが他のポリシーを満たしていることを確認するポリシーを作成します。

ユーザーが複数のポリシーを同時に満たす必要がある場合に対応するには、次の方法の "いずれか" を採用します。

• AuthorizeView に対して、ユーザーが他の複数のポリシーを満たしていることを確認するポリシーを作成します。

• 複数の AuthorizeView コンポーネントでポリシーを入れ子にします。

  <AuthorizeView Policy="Over21">
      <AuthorizeView Policy="LivesInCalifornia">
          <p>You satisfy the 'Over21' and 'LivesInCalifornia' policies.</p>
      </AuthorizeView>
  </AuthorizeView>
  

要求ベースの承認は、ポリシーベースの承認の特殊なケースです。 たとえば、ユーザーが特定の要求持つことを必須にするポリシーを定義できます。 詳細については、「ASP.NET Core でのポリシー ベースの認可」を参照してください。

Roles も Policy も指定されていない場合、AuthorizeView には既定のポリシーが使われます。

• 認証された (サインインした) ユーザーが認可されます。
• 認証されていない (サインアウトした) ユーザーは認可されません。

.NET 文字列の比較では大文字と小文字が区別されるため、ロール名とポリシー名の照合でも大文字と小文字が区別されます。 たとえば、Admin (大文字 A) は、admin (小文字 a) と同じロールとして扱われません。

通常、パスカル ケースはロール名とポリシー名に使用されますが (例: BillingAdministrator)、パスカル ケースの使用は厳密な要件ではありません。 キャメル ケース、ケバブ ケース、スネーク ケースなど、さまざまなケース スキームが許可されています。 ロールとポリシーの名前にスペースを使うことは一般的ではありませんが、フレームワークでは許可されています。 たとえば、billing administrator は .NET アプリでは一般的ではないロールまたはポリシーの名前の形式ですが、有効なロールまたはポリシーの名前です。

非同期認証中に表示されるコンテンツ

Blazor では、認証状態を非同期的に判別できます。 このアプローチの主なシナリオは、認証のために外部エンドポイントに要求を送信するクライアント側 Blazor アプリです。

認証の処理中は、AuthorizeView にはコンテンツが表示されません。 認証の処理中にコンテンツを表示するには、Authorizing パラメーターにコンテンツを割り当てます。

<AuthorizeView>
    <Authorized>
        <p>Hello, @context.User.Identity?.Name!</p>
    </Authorized>
    <Authorizing>
        <p>You can only see this content while authentication is in progress.</p>
    </Authorizing>
</AuthorizeView>

このアプローチは通常、サーバー側 Blazor アプリには適用されません。 サーバー側 Blazor アプリでは、状態が確立されるとすぐに認証状態が認識されます。 Authorizing コンテンツをアプリの AuthorizeView コンポーネントで提供することはできますが、このコンテンツが表示されることはありません。

[Authorize] 属性

[Authorize] 属性 は、Razor コンポーネントで使用できます。

@page "/"
@attribute [Authorize]

You can only see this if you're signed in.

重要

[Authorize]は、Blazor ルーター経由で到達した @page コンポーネントでのみ使用します。 承認はルーティングの一面としてのみ実行され、ページ内にレンダリングされた子コンポーネントに対しては実行され "ません"。 ページ内の特定部分の表示を承認するには、代わりに AuthorizeView を使用します。

[Authorize] 属性 は、ロールベースまたはポリシーベースの承認もサポートしています。 ロールベースの承認の場合は、Roles パラメーターを使用します。

@page "/"
@attribute [Authorize(Roles = "Admin, Superuser")]

<p>You can only see this if you're in the 'Admin' or 'Superuser' role.</p>

ポリシーベースの承認の場合は、Policy パラメーターを使用します。

@page "/"
@attribute [Authorize(Policy = "Over21")]

<p>You can only see this if you satisfy the 'Over21' policy.</p>

Roles も Policy も指定されていない場合、[Authorize] には既定のポリシーが使われます。

• 認証された (サインインした) ユーザーが認可されます。
• 認証されていない (サインアウトした) ユーザーは認可されません。

ユーザーが承認されない場合、アプリで Router コンポーネントを使用して未承認コンテンツをカスタマイズしていない場合は、このフレームワークでは次のフォールバック メッセージが自動的に表示されます。

Not authorized.

リソース承認

リソースのユーザーを承認するには、要求のルート データを AuthorizeRouteView の Resource パラメーターに渡します。

要求されたルートの Router.Found コンテンツで、次のようにします。

<AuthorizeRouteView Resource="routeData" RouteData="routeData" 
    DefaultLayout="typeof(MainLayout)" />

手続き型ロジックでの承認状態データの受け渡し方法と使用方法の詳細については、「認証状態をカスケード パラメーターとして公開する」セクションを参照してください。

AuthorizeRouteView がリソースのルート データを受け取ると、承認ポリシーから RouteData.PageType と RouteData.RouteValues へのアクセスが可能になり、カスタム ロジックで承認決定ができるようになります。

次の例では、アプリの承認サービス構成 (AddAuthorizationCore) の AuthorizationOptions で、次のロジックを使用して EditUser ポリシーが作成されます。

• id のキーを持つルート値が存在するかどうかを確認します。 そのキーが存在する場合、ルート値を value に格納します。
• id という名前の変数内に、value を文字列として格納するか、空の文字列値 (string.Empty) を設定します。
• id が空の文字列でないとき、文字列の値が EMP で始まる場合は、ポリシーが満たされていることをアサートします (true を返します)。 それ以外の場合は、ポリシーが失敗したことをアサートします (false を返します)。

Program ファイルで次の操作を行います。

• Microsoft.AspNetCore.Components と System.Linq の名前空間を追加します。

  using Microsoft.AspNetCore.Components;
  using System.Linq;
  

• ポリシーを追加します。

  options.AddPolicy("EditUser", policy =>
      policy.RequireAssertion(context =>
      {
          if (context.Resource is RouteData rd)
          {
              var routeValue = rd.RouteValues.TryGetValue("id", out var value);
              var id = Convert.ToString(value, 
                  System.Globalization.CultureInfo.InvariantCulture) ?? string.Empty;
  
              if (!string.IsNullOrEmpty(id))
              {
                  return id.StartsWith("EMP", StringComparison.InvariantCulture);
              }
          }
  
          return false;
      })
  );
  

上記の例は、過度に単純化された承認ポリシーであり、実施例で概念を示すためだけに使用されています。 承認ポリシーの作成と構成の詳細については、「ASP.NET Core でのポリシーベースの認可」を参照してください。

次の EditUser コンポーネントでは、/users/{id}/edit のリソースにユーザーの識別子 ({id}) のルート パラメーターが含まれています。 コンポーネントで前述の EditUser 承認ポリシーを使用して、id のルート値が EMP で始まるかどうかを判断します。 id が EMP で始まる場合、ポリシーは成功し、コンポーネントへのアクセスが承認されます。 id が EMP 以外の値で始まり、id が空の文字列である場合、ポリシーは失敗し、コンポーネントは読み込まれません。

EditUser.razor:

@page "/users/{id}/edit"
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize(Policy = "EditUser")]

<h1>Edit User</h1>

<p>The "EditUser" policy is satisfied! <code>Id</code> starts with 'EMP'.</p>

@code {
    [Parameter]
    public string? Id { get; set; }
}

Router コンポーネントを使用して未承認コンテンツをカスタマイズする

Router コンポーネントを AuthorizeRouteView コンポーネントとともに使用すると、以下の場合にアプリがカスタム コンテンツを指定できます。

• ユーザーはコンポーネントに適用されている [Authorize] 条件に失敗します。 <NotAuthorized> 要素のマークアップが表示されます。 [Authorize] 属性については、「[Authorize] 属性」セクションをご覧ください。
• 非同期の認可が進行中です。これは通常、ユーザーの認証プロセスが進行中であることを意味します。 <Authorizing> 要素のマークアップが表示されます。

重要

<NotAuthorized> および <NotFound> コンテンツを表示する Blazor ルーター機能は、静的なサーバー側レンダリング (静的 SSR) 中は動作しません。これは、要求処理は完全に ASP.NET Core ミドルウェア パイプライン要求処理によって処理され、未承認の要求または不正な要求については Razor コンポーネントは一切表示されないためです。 静的 SSR 中の未承認の要求と不正な要求は、サーバー側の手法を使用して処理します。 詳細については、「ASP.NET Core Blazor のレンダリング モード」をご覧ください。

<Router ...>
    <Found ...>
        <AuthorizeRouteView ...>
            <NotAuthorized>
                ...
            </NotAuthorized>
            <Authorizing>
                ...
            </Authorizing>
        </AuthorizeRouteView>
    </Found>
</Router>

Authorized と NotAuthorized のコンテンツには、他の対話型コンポーネントなど、任意の項目を含めることができます。

Note

前述の例では、アプリの Program ファイルにカスケード型の認証状態サービスを登録する必要があります。

builder.Services.AddCascadingAuthenticationState();

NotAuthorized コンテンツが指定されていない場合、AuthorizeRouteView は次のフォールバック メッセージを使用します。

Not authorized.

Blazor WebAssembly プロジェクト テンプレートを基にして、認証を有効にして作成されたアプリには、RedirectToLogin コンポーネントが含まれます。これは、Router コンポーネントの <NotAuthorized> コンテンツに配置されています。 ユーザーが認証されていない場合 (context.User.Identity?.IsAuthenticated != true)、RedirectToLogin コンポーネントはブラウザーを authentication/login エンドポイントにリダイレクトし、認証を行います。 ユーザーは ID プロバイダーで認証された後、要求された URL に戻ります。

手続き型ロジック

手続き型ロジックの一部としてアプリで承認規則をチェックする必要がある場合、型 Task<AuthenticationState> のカスケード パラメーターを使用してユーザーの ClaimsPrincipal を取得します。 ポリシーを評価するために、Task< AuthenticationState > を IAuthorizationService などの他のサービスと組み合わせることができます。

次に例を示します。

• user.Identity.IsAuthenticated は、認証された (サインインした) ユーザーのコードを実行します。
• user.IsInRole("admin") は、'管理者' ロールのユーザーに対してコードを実行します。
• (await AuthorizationService.AuthorizeAsync(user, "content-editor")).Succeeded は、'content-editor' ポリシーを満たすユーザーに対してコードを実行します。

プロジェクト テンプレートから作成されたサーバー側 Blazor アプリには、適切な名前空間が含まれます。 クライアント側 Blazor アプリで、コンポーネント内またはアプリの _Imports.razor ファイル内に Microsoft.AspNetCore.Authorization および Microsoft.AspNetCore.Components.Authorization の名前空間があることを確認します。

@using Microsoft.AspNetCore.Authorization
@using Microsoft.AspNetCore.Components.Authorization

ProceduralLogic.razor:

@page "/procedural-logic"
@inject IAuthorizationService AuthorizationService

<h1>Procedural Logic Example</h1>

<button @onclick="@DoSomething">Do something important</button>

@code {
    [CascadingParameter]
    private Task<AuthenticationState>? authenticationState { get; set; }

    private async Task DoSomething()
    {
        if (authenticationState is not null)
        {
            var authState = await authenticationState;
            var user = authState?.User;

            if (user is not null)
            {
                if (user.Identity is not null && user.Identity.IsAuthenticated)
                {
                    // ...
                }

                if (user.IsInRole("Admin"))
                {
                    // ...
                }

                if ((await AuthorizationService.AuthorizeAsync(user, "content-editor"))
                    .Succeeded)
                {
                    // ...
                }
            }
        }
    }
}

エラーのトラブルシューティング

一般的なエラー:

• 承認には、型 Task<AuthenticationState> のカスケード パラメーターが必要です。 これを指定するには CascadingAuthenticationState の使用を検討してください。

• authenticationStateTask について null 値を受け取ります

このプロジェクトは、サーバー側 Blazor テンプレートを使用し、認証を有効にして作成されなかった可能性があります。

.NET 7 以前では、UI ツリーの一部を <CascadingAuthenticationState> でラップします (例: Blazor ルーターの周囲)。

<CascadingAuthenticationState>
    <Router ...>
        ...
    </Router>
</CascadingAuthenticationState>

.NET 8 以降では、CascadingAuthenticationState コンポーネントを使用しないでください。

- <CascadingAuthenticationState>
      <Router ...>
          ...
      </Router>
- </CascadingAuthenticationState>

代わりに、Program ファイル内のサービス コレクションにカスケード型の認証状態サービスを追加します。

builder.Services.AddCascadingAuthenticationState();

CascadingAuthenticationState コンポーネント (.NET 7 以前) または AddCascadingAuthenticationState によって提供されるサービス (.NET 8 以降) によって、Task<AuthenticationState> カスケード型パラメーターが提供されます。このパラメーターは、基盤となる AuthenticationStateProvider 依存関係の挿入サービスから値を受け取ります。

個人を特定できる情報 (PII)

Microsoft は、個人を特定できる情報 (PII) についてドキュメントで言及する場合、個人データに関する GDPR 定義 (GDPR 4.1) を使用します。

PII とは、識別された、または識別可能な自然人に関連する情報を指します。 識別可能な自然人とは、以下のいずれかにより、直接または間接的に特定できる自然人を指します。

• 名前
• 識別番号
• 所在地の座標
• オンライン識別子
• その他の特定の要素
  • 物理
  • 生理学的
  • 遺伝的
  • 精神的 (心理的)
  • 経済的
  • 文化
  • 社会的アイデンティティ

その他のリソース

• サーバー側アプリおよび Blazor Web App に関するリソース
  • クイック スタート: Microsoft でのサインインを ASP.NET Core Web アプリに追加する
  • クイック スタート: Microsoft ID プラットフォームを使用して ASP.NET Core Web API を保護する
  • プロキシ サーバーとロード バランサーを使用するために ASP.NET Core を構成する: 次のガイダンスを含む:
    • 転送されたヘッダー ミドルウェアを使用した、プロキシ サーバーと内部ネットワークの間での HTTPS スキーム情報の保持。
    • 追加のシナリオとユース ケース (手動スキーム構成を含む)、正しい要求ルーティングのための要求パスの変更、Linux および IIS 以外のリバース プロキシのための要求スキームの転送。
• Microsoft ID プラットフォームのドキュメント
  • 概要
  • Microsoft ID プラットフォームにおける OAuth 2.0 プロトコルと OpenID Connect プロトコル
  • Microsoft ID プラットフォームと OAuth 2.0 認証コード フロー
  • Microsoft ID プラットフォーム ID トークン
  • Microsoft ID プラットフォーム アクセス トークン
• ASP.NET Core のセキュリティ トピック
• ASP.NET Core で Windows 認証を構成する
• ASP.NET Core Blazor アプリにおける IHttpContextAccessor/HttpContext
• Authentication.MSAL JavaScript ライブラリのカスタム バージョンをビルドする
• Awesome Blazor: Authentication コミュニティ サンプル リンク
• ASP.NET Core Blazor Hybrid の認証と認可