ASP.NET Core Blazor の認証と承認

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

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

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

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

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 (この記事)

クライアント側およびサーバー側のローカル開発とテストでは、シークレット マネージャー ツールを使用して機密性の高い資格情報をセキュリティで保護します。

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場合は、呼び出しの後に配置するUseAuthenticationUseAuthorization必要があります。

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 としてエンコードしてサーバーに送信したときだけです。その理由は、有効なフォームのエンコードタイプはこれらだけであるからです。

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

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

認証

Blazor は、既存の ASP.NET Core 認証メカニズムを使用してユーザーの identity を確認します。 詳細なメカニズムは、Blazor アプリのホスティング方法、サーバー側またはクライアント側かによって異なります。

サーバー側の Blazor の認証

対話形式でレンダリングされたサーバー側の Blazor は、クライアントとの SignalR 接続を介して動作します。 SignalR ベースのアプリの認証は、接続が確立したときに処理されます。 認証は、cookie または他の何らかのベアラー トークンに基づいて行うことができますが、SignalR ハブを経由し、回線内で完全に管理されます。

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

サーバー側認証の詳細については、「ASP.NET Core のサーバー側 Blazor アプリをセキュリティで保護する」をご覧ください。

Razor コンポーネント内の IHttpContextAccessor/HttpContext

有効な HttpContext が使用できないため、対話型レンダリングでは IHttpContextAccessor を避ける必要があります。

IHttpContextAccessor は、サーバー上で静的にレンダリングされるコンポーネントに対して使用することができます。 ただし、可能であれば使用を避けることをお勧めします。

HttpContext は、App コンポーネント (Components/App.razor) 内のヘッダーやその他のプロパティの検査や変更などの一般的なタスク用に、"静的にレンダリングされたルート コンポーネント" 内でのみ、カスケード パラメーターとして使用できます。 対話型レンダリングの場合、この値は常に null です。

[CascadingParameter]
public HttpContext? HttpContext { get; set; }

対話型コンポーネント内で HttpContext が必要なシナリオの場合は、サーバーから永続的なコンポーネントの状態を介してデータを取り込むことをお勧めします。 詳細については、「サーバーサイド ASP.NET Core Blazor のセキュリティに関するその他のシナリオ」を参照してください。

共有状態

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

警告

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

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

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

クライアント側の 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 コンテンツが選択的に表示されます。 このアプローチは、ユーザーに対してデータを表示するだけで済み、手続き型ロジックでユーザーの identity を使用する必要がない場合に便利です。

このコンポーネントでは、型 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="SecureMethod">Authorized Only Button</button></p>
    </Authorized>
    <NotAuthorized>
        <p>You're not authorized.</p>
    </NotAuthorized>
</AuthorizeView>

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

前の例の <button> 要素の SecureMethod メソッドなど、承認された要素の既定のイベント ハンドラーは、承認されたユーザーのみが呼び出すことができます。

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 でのロールベースの認可」を参照してください。

ポリシーベースの認可の場合、1 つのポリシーで 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.

重要

Blazor ルーター経由で送信される @page コンポーネントでのみ、[Authorize] を使ってください。 承認はルーティングの一面としてのみ実行され、ページ内にレンダリングされた子コンポーネントに対しては実行され "ません"。 ページ内の特定部分の表示を承認するには、代わりに 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 プロジェクト テンプレートから作成されたアプリには、 Router コンポーネントの <NotAuthorized> コンテンツに配置される RedirectToLogin コンポーネントが含まれています。 ユーザーが認証されていない場合 (context.User.Identity?.IsAuthenticated != true)、RedirectToLogin コンポーネントはブラウザーを authentication/login エンドポイントにリダイレクトし、認証を行います。 ユーザーは identity プロバイダーで認証された後、要求された 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 ツリーの一部 (たとえば Blazor ルーターなど) を <CascadingAuthenticationState> でラップします。

<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 とは、特定の自然人または特定可能な自然人に関連するあらゆる情報を指します。 特定可能な自然人とは、以下のいずれかを使用して、直接または間接的に特定できる自然人を指します。

• 名前
• ID 番号
• 位置座標
• オンライン識別子
• その他の特定要因
  • 物理
  • 生理的
  • 遺伝的
  • 精神的 (心理的)
  • 経済的
  • 文化
  • ソーシャル identity

その他のリソース

• Microsoft identity プラットフォーム ドキュメント
  • 概要
  • Microsoft identity プラットフォームにおける OAuth 2.0 プロトコルと OpenID Connect プロトコル
  • Microsoft identity プラットフォームと OAuth 2.0 認証コード フロー
  • Microsoft identity プラットフォーム ID トークン
  • Microsoft identity プラットフォーム アクセス トークン
• ASP.NET Core Security の概要
• ASP.NET Core で Windows 認証を構成する
• Authentication.MSAL JavaScript ライブラリのカスタム バージョンをビルドする
• すばらしい Blazor: 認証 コミュニティのサンプル リンク
• ASP.NET Core Blazor Hybrid の認証と認可