web-dev-qa-db-ja.com

複数のJWT Bearer認証を使用する

ASP.NET Core 2で複数のJWTトークン発行者をサポートすることは可能ですか？外部サービス用のAPIを提供し、JWTトークンの2つのソース-FirebaseとカスタムJWTトークン発行者を使用する必要があります。 ASP.NETコアでは、Bearer認証スキームのJWT認証を設定できますが、1つの機関に対してのみです：

  services
        .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
        .AddJwtBearer(options =>
        {
            options.Authority = "https://securetoken.google.com/my-firebase-project"
            options.TokenValidationParameters = new TokenValidationParameters
                {
                    ValidateIssuer = true,
                    ValidIssuer = "my-firebase-project"
                    ValidateAudience = true,
                    ValidAudience = "my-firebase-project"
                    ValidateLifetime = true
                };
        }

複数の発行者と対象ユーザーを設定できますが、複数の機関を設定することはできません。

firebase-authenticationasp.net-core-mvcjwtasp.net-core-2.0
35
Sane

あなたは完全にあなたが望むものを達成することができます：

services
    .AddAuthentication()
    .AddJwtBearer("Firebase", options =>
    {
        options.Authority = "https://securetoken.google.com/my-firebase-project"
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = "my-firebase-project"
            ValidateAudience = true,
            ValidAudience = "my-firebase-project"
            ValidateLifetime = true
        };
    })
    .AddJwtBearer("Custom", options =>
    {
        // Configuration for your custom
        // JWT tokens here
    });

services
    .AddAuthorization(options =>
    {
        options.DefaultPolicy = new AuthorizationPolicyBuilder()
            .RequireAuthenticatedUser()
            .AddAuthenticationSchemes("Firebase", "Custom")
            .Build();
    });

コードとそのコードの違いを見てみましょう。

AddAuthenticationにはパラメーターがありません

デフォルトの認証スキームを設定すると、すべてのリクエストで認証ミドルウェアはデフォルトの認証スキームに関連付けられた認証ハンドラーを実行しようとします。現在、2つの有効な認証スキームがあるため、そのうちの1つを実行しても意味がありません。

AddJwtBearerの別のオーバーロードを使用します

認証を追加するすべてのAddXXXメソッドには、いくつかのオーバーロードがあります。

現在、同じ認証方法を2回使用していますが、認証スキームは一意である必要があるため、2番目のオーバーロードを使用する必要があります。

デフォルトポリシーを更新する

リクエストは自動的に認証されなくなるため、一部のアクションに[Authorize]属性を設定すると、リクエストが拒否され、HTTP 401が発行されます。

認証ハンドラーにリクエストを認証する機会を与えたいので、それは私たちが望むものではないので、FirebaseとCustomの両方の認証スキームがであることを示すことにより、認可システムのデフォルトポリシーを変更しますリクエストを認証しようとしました。

それはあなたがいくつかのアクションをより制限することを妨げるものではありません。 [Authorize]属性には、有効な認証スキームをオーバーライドできる AuthenticationSchemes プロパティがあります。

より複雑なシナリオがある場合は、 policy-based authorization を使用できます。公式のドキュメントは素晴らしいと思います。

Firebaseによって発行されたJWTトークンでのみ使用できるアクションがあり、特定の値を持つクレームが必要であると想像してみましょう。次のようにできます。

// Authentication code omitted for brevity

services
    .AddAuthorization(options =>
    {
        options.DefaultPolicy = new AuthorizationPolicyBuilder()
            .RequireAuthenticatedUser()
            .AddAuthenticationSchemes("Firebase", "Custom")
            .Build();

        options.AddPolicy("FirebaseAdministrators", new AuthorizationPolicyBuilder()
            .RequireAuthenticatedUser()
            .AddAuthenticationSchemes("Firebase")
            .RequireClaim("role", "admin")
            .Build());
    });

その後、いくつかのアクションで[Authorize(Policy = "FirebaseAdministrators")]を使用できます。

72
Mickaël Derriey