Vous pouvez totalement réaliser ce que vous voulez:
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 =>
{
});
services
.AddAuthorization(options =>
{
options.DefaultPolicy = new AuthorizationPolicyBuilder()
.RequireAuthenticatedUser()
.AddAuthenticationSchemes("Firebase", "Custom")
.Build();
});
Passons en revue les différences entre votre code et celui-là.
AddAuthentication
n'a pas de paramètre
Si vous définissez un schéma d'authentification par défaut, à chaque demande, le middleware d'authentification essaiera d'exécuter le gestionnaire d'authentification associé au schéma d'authentification par défaut. Puisque nous avons maintenant deux schémas d'authentification opssibles, il est inutile d'en exécuter un.
Utilisez une autre surcharge de AddJwtBearer
Chaque AddXXX
méthode unique pour ajouter une authentification a plusieurs surcharges:
Maintenant, comme vous utilisez la même méthode d'authentification deux fois mais que les schémas d'authentification doivent être uniques, vous devez utiliser la deuxième surcharge.
Mettre à jour la politique par défaut
Étant donné que les demandes ne seront plus authentifiées automatiquement, le fait de placer des [Authorize]
attributs sur certaines actions entraînera le rejet des demandes et un HTTP 401
sera émis.
Puisque ce n'est pas ce que nous voulons parce que nous voulons donner aux gestionnaires d'authentification une chance d'authentifier la demande, nous changeons la politique par défaut du système d'autorisation en indiquant à la fois les schémas d'authentification Firebase
et Custom
doivent être essayés pour authentifier la demande.
Cela ne vous empêche pas d'être plus restrictif sur certaines actions; l' [Authorize]
attribut a une AuthenticationSchemes
propriété qui vous permet de remplacer les schémas d'authentification valides.
Si vous avez des scénarios plus complexes, vous pouvez utiliser l' autorisation basée sur des stratégies . Je trouve que la documentation officielle est excellente.
Imaginons que certaines actions ne soient disponibles que pour les jetons JWT émis par Firebase et doivent avoir une revendication avec une valeur spécifique; vous pouvez le faire de cette façon:
services
.AddAuthorization(options =>
{
options.DefaultPolicy = new AuthorizationPolicyBuilder()
.RequireAuthenticatedUser()
.AddAuthenticationSchemes("Firebase", "Custom")
.Build();
options.AddPolicy("FirebaseAdministrators", new AuthorizationPolicyBuilder()
.RequireAuthenticatedUser()
.AddAuthenticationSchemes("Firebase")
.RequireClaim("role", "admin")
.Build());
});
Vous pouvez ensuite utiliser [Authorize(Policy = "FirebaseAdministrators")]
sur certaines actions.
Un dernier point à noter: si vous attrapez des AuthenticationFailed
événements et n'utilisez rien d'autre que la première AddJwtBearer
stratégie, vous pouvez voir que IDX10501: Signature validation failed. Unable to match key...
cela est dû au fait que le système vérifie chacun AddJwtBearer
à son tour jusqu'à ce qu'il obtienne une correspondance. L'erreur peut généralement être ignorée.