最小限の API での認証と承認

Note

これは、この記事の最新バージョンではありません。現在のリリースについては、この記事の .NET 10 バージョンを参照してください。

警告

このバージョンの ASP.NET Core はサポート対象から除外されました。詳細については、 .NET および .NET Core サポートポリシーを参照してください。現在のリリースについては、この記事の .NET 10 バージョンを参照してください。

Minimal API では、ASP.NET Core で使用できるすべての認証と認可のオプションがサポートされ、認証を扱うエクスペリエンスを強化するための追加機能もいくつか用意されています。

認証と認可における重要な概念

認証は、ユーザーの ID を決定するプロセスです。認可は、ユーザーがリソースにアクセスできるかどうかを判断するプロセスです。 ASP.NET Core では、認証と認可の両方のシナリオで、類似した実装のセマンティクスが共有されます。認証は、認証サービス IAuthenticationService によって処理されます。これは、認証ミドルウェアによって使用されます。認可は、認可サービス IAuthorizationService によって処理されます。これは、認可ミドルウェアによって使用されます。

認証サービスは、登録済みの認証ハンドラーを使用して、認証関連のアクションを完了します。認証関連のアクションの例としては、ユーザーの認証やユーザーのサインアウトがあります。認証スキームとは、認証ハンドラーとその構成オプションを一意に識別するために使用される名前のことです。認証ハンドラーは、OAuth や OIDC といった特定の認証方式を指定したうえで、認証方式を実装し、ユーザーのクレームを生成する役割を担います。構成オプションもその方式に固有であり、リダイレクト URI などの認証動作に影響を与える構成がハンドラーに提供されます。

認可レイヤーでは、リソースへのユーザーアクセスを判断するための方式が 2 つあります。

ロールベースの方式では、ユーザーに割り当てられているロール (Administrator や User など) に基づいてユーザーのアクセスを判断します。ロールベースの認可について詳しくは、ロールベースの認可に関するドキュメントを参照してください。
クレームベースの方式では、中央機関によって発行されたクレームに基づいてユーザーのアクセスを判断します。クレームベースの認可について詳しくは、クレームベースの認可に関するドキュメントを参照してください。

ASP.NET Core では、両方の方式が認可要件に取り込まれています。認可サービスでは、認可ハンドラーを利用して、特定のユーザーがリソースに適用される認可要件を満たしているかどうかを判断します。

最小限のアプリにおける認証の有効化

認証を有効にするには、AddAuthentication を呼び出して、アプリのサービスプロバイダーに必要な認証サービスを登録します。

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddAuthentication();
var app = builder.Build();

app.MapGet("/", () => "Hello World!");
app.Run();

通常は、特定の認証方法が使用されます。次のサンプルでは、JWT ベアラーベースの認証をサポートするようにアプリが構成されています。この例では、Microsoft.AspNetCore.Authentication.JwtBearer NuGet パッケージで使用できる API を使用します。

var builder = WebApplication.CreateBuilder(args);
// Requires Microsoft.AspNetCore.Authentication.JwtBearer
builder.Services.AddAuthentication().AddJwtBearer();
var app = builder.Build();

app.MapGet("/", () => "Hello World!");
app.Run();

既定では、WebApplication では、特定の認証サービスや認可サービスが有効である場合、認証ミドルウェアや認可ミドルウェアが自動的に登録されます。次のサンプルでは、UseAuthentication または UseAuthorization を呼び出してミドルウェアを登録する必要はありません。WebApplication または AddAuthentication が呼び出された後に、AddAuthorization によって自動的に登録されるためです。

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddAuthentication().AddJwtBearer();
builder.Services.AddAuthorization();
var app = builder.Build();

app.MapGet("/", () => "Hello World!");
app.Run();

ミドルウェアの順序を管理するケースなど、場合によっては、認証と認可を明示的に登録する必要があります。次のサンプルでは、CORS ミドルウェアが実行された "後に" 認証ミドルウェアが実行されます。ミドルウェアとこのような自動動作について詳しくは、「Minimal API アプリのミドルウェア」を参照してください。

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCors();
builder.Services.AddAuthentication().AddJwtBearer();
builder.Services.AddAuthorization();

var app = builder.Build();

app.UseCors();
app.UseAuthentication();
app.UseAuthorization();

app.MapGet("/", () => "Hello World!");
app.Run();

認証方式の構成

通常、認証戦略はオプションを介して読み込まれるさまざまな構成をサポートします。最小限のアプリでは、次の認証戦略の構成からの読み込みオプションがサポートされています。

ASP.NET Core フレームワークは、Authentication:Schemes:{SchemeName} の configuration セクションでこれらのオプションを見つけることを期待しています。次のサンプルでは、2 つの異なるスキーム Bearer と LocalAuthIssuer が、それぞれのオプションと共に定義されています。 Authentication:DefaultScheme オプションを使って、使用される既定の認証方式を構成できます。

{
  "Authentication": {
    "DefaultScheme":  "LocalAuthIssuer",
    "Schemes": {
      "Bearer": {
        "ValidAudiences": [
          "https://localhost:7259",
          "http://localhost:5259"
        ],
        "ValidIssuer": "dotnet-user-jwts"
      },
      "LocalAuthIssuer": {
        "ValidAudiences": [
          "https://localhost:7259",
          "http://localhost:5259"
        ],
        "ValidIssuer": "local-auth"
      }
    }
  }
}

Program.cs では、次の 2 つの JWT ベアラーベースの認証戦略が登録されます。

"Bearer" スキーム名。
"LocalAuthIssuer" スキーム名。

"Bearer" は JWT ベアラーベースが有効なアプリの一般的な既定のスキームですが、上記の例のように、DefaultScheme プロパティを設定することで既定のスキームをオーバーライドできます。

スキーム名は、認証方式を一意に識別するために使用され、次の例に示すように、構成から認証オプションを解決するときに参照キーとして使用されます。

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication()
  .AddJwtBearer()
  .AddJwtBearer("LocalAuthIssuer");
  
var app = builder.Build();

app.MapGet("/", () => "Hello World!");
app.Run();

最小限のアプリにおける認可ポリシーの構成

認証は、API に対するユーザーの ID を識別して検証するために使用されます。認可は、API でリソースへのアクセスを検証および確認するために使用され、IAuthorizationService 拡張メソッドによって登録された AddAuthorization によって容易になります。次のシナリオでは、ユーザーが /hello スコープクレームを使って admin ロールクレームを提示する必要がある、greetings_api リソースが追加されます。

リソースに対する認可要件の構成は、次が必要になる 2 段階のプロセスです。

ポリシーで認可要件をグローバルに構成する。
個々のポリシーをリソースに適用する。

以下のコードでは、次のことを行う AddAuthorizationBuilder が呼び出されます。

認可関連のサービスを DI コンテナーに追加します。
認可ポリシーを直接登録するために使用できる AuthorizationBuilder を返します。

このコードでは、2 つの認可要件をカプセル化する、admin_greetings という名前の新しい認可ポリシーを作成します。

RequireRole ロールを持つユーザーに対する、admin を介したロールベースの要件。
ユーザーが RequireClaim スコープクレームを提供する必要がある、greetings_api を介したクレームベースの要件。

admin_greetings ポリシーは、/hello エンドポイントに必要なポリシーとして指定されます。

using Microsoft.Identity.Web;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthorizationBuilder()
  .AddPolicy("admin_greetings", policy =>
        policy
            .RequireRole("admin")
            .RequireClaim("scope", "greetings_api"));

var app = builder.Build();

app.MapGet("/hello", () => "Hello world!")
  .RequireAuthorization("admin_greetings");

app.Run();

開発テストに `dotnet user-jwts` を使用する

この記事全体を通して、JWT ベアラーベースの認証で構成されたアプリが使用されています。 JWT ベアラーベースの認証では、クライアントが ID と要求を検証するために要求ヘッダーにトークンを提示する必要があります。通常、これらのトークンは、ID サーバーなどの中央機関によって発行されます。

ローカルコンピューター上で開発している場合は、dotnet user-jwts ツールを使ってベアラートークンを作成できます。

dotnet user-jwts create

Note

プロジェクトで呼び出されると、ツールによって、生成されたトークンに一致する認証オプションが appsettings.json に自動的に追加されます。

トークンは、さまざまなカスタマイズによって構成できます。たとえば、前のコードの認可ポリシーで想定される、admin ロールと greetings_api スコープ用のトークンを作成する場合:

dotnet user-jwts create --scope "greetings_api" --role "admin"

その後、生成されたトークンを、任意のテストツールでヘッダーの一部として送信できます。たとえば、curl を使う場合:

curl -i -H "Authorization: Bearer {token}" https://localhost:{port}/hello

dotnet user-jwts ツールについて詳しくは、完全なドキュメントを参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-04-18