Vue d’ensemble de l’authentification ASP.NET Core

  • Article

Par Mike Rousos

L’authentification est le processus de détermination de l’identity d’un utilisateur. L’autorisation est le processus consistant à déterminer si un utilisateur a accès à une ressource. Dans ASP.NET Core, l’authentification est gérée par le service d’authentification, IAuthenticationService, qui est utilisé par l’intergiciel (middleware) d’authentification. Le service d’authentification utilise des gestionnaires d’authentification inscrits pour effectuer des actions liées à l’authentification. Voici des exemples d’actions liées à l’authentification :

  • Authentifier un utilisateur.
  • Répondre quand un utilisateur non authentifié tente d’accéder à une ressource restreinte.

Les gestionnaires d’authentification inscrits et leurs options de configuration sont appelés « schémas ».

Les schémas d’authentification sont spécifiés en inscrivant les services d’authentification dans Program.cs :

Par exemple, le code suivant inscrit les services et les gestionnaires d’authentification pour les schémas d’authentification de cookie et de porteur JWT :

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("CookieSettings", options));

Le paramètre JwtBearerDefaults.AuthenticationScheme de AddAuthentication est le nom du schéma à utiliser par défaut quand un schéma spécifique n’est pas demandé.

Si plusieurs schémas sont utilisés, les stratégies d’autorisation (ou les attributs d’autorisation) peuvent spécifier le ou les schémas d’authentification dont elles dépendent pour authentifier l’utilisateur. Dans l’exemple ci-dessus, le schéma d’authentification cookie peut être utilisé en spécifiant son nom (CookieAuthenticationDefaults.AuthenticationScheme par défaut, bien qu’un autre nom puisse être fourni lors de l’appel de AddCookie).

Dans certains cas, l’appel à AddAuthentication est effectué automatiquement par d’autres méthodes d’extension. Par exemple, lors de l’utilisation de ASP.NET Core Identity, AddAuthentication est appelé en interne.

L’intergiciel d’authentification est ajouté dans Program.cs en appelant UseAuthentication. L’appel de UseAuthentication inscrit le middleware qui utilise les schémas d’authentification précédemment inscrits. Appelez UseAuthentication avant tout middleware dépendant de l’authentification des utilisateurs.

Concepts d’authentification

L’authentification doit fournir le ClaimsPrincipal pour que l’automatiquement puisse prendre des décisions d’autorisation en fonction de celui-ci. Il existe plusieurs approches des schémas d’authentification pour sélectionner le gestionnaire d’authentification responsable de la génération de l’ensemble correct de revendications :

Lorsqu'un seul schéma d'authentification est enregistré, il devient le schéma par défaut. Si plusieurs schémas sont enregistrés et que le schéma par défaut n’est pas spécifié, un schéma doit être spécifié dans l’attribut d’autorisation ; sinon, l’erreur suivante est levée :

InvalidOperationException : Aucun authenticationScheme n’a été spécifié et aucun DefaultAuthenticateScheme n’a été trouvé. Les schémas par défaut peuvent être définis en utilisant AddAuthentication(string defaultScheme) ou AddAuthentication(Action<options_authentification> configureOptions).

DefaultScheme

Lorsqu'un seul schéma d'authentification est enregistré, le schéma d’authentification unique :

Pour désactiver automatiquement l’utilisation du schéma d’authentification unique en tant que DefaultScheme, appelez AppContext.SetSwitch("Microsoft.AspNetCore.Authentication.SuppressAutoDefaultScheme").

Schéma d’authentification

Le schéma d’authentification peut sélectionner le gestionnaire d’authentification responsable de la génération de l’ensemble correct de revendications. Pour plus d’informations, consultez Autoriser avec un schéma spécifique.

Un schéma d’authentification est un nom qui correspond à :

  • Un gestionnaire d’authentification.
  • Des options pour la configuration de cette instance spécifique du gestionnaire.

Les schémas sont utiles comme mécanisme pour faire référence au comportement d’authentification, de demande et d’interdiction du gestionnaire associé. Par exemple, une stratégie d’autorisation peut utiliser des noms de schéma pour spécifier le ou les schémas d’authentification à utiliser pour authentifier l’utilisateur. Lors de la configuration de l’authentification, il est courant de spécifier le schéma d’authentification par défaut. Le schéma par défaut est utilisé sauf si une ressource demande un schéma spécifique. Il est également possible de :

  • Spécifier différents schémas par défaut à utiliser pour les actions d’authentification, de demande et d’interdiction.
  • Combiner plusieurs schémas en un seul en utilisant des schémas de stratégie.

Gestionnaire d’authentification

Un gestionnaire d’authentification :

En fonction de la configuration du schéma d’authentification et du contexte de la demande entrante, les gestionnaires d’authentification :

  • Construisent des objets AuthenticationTicket représentant l’identity de l’utilisateur si l’authentification réussit
  • Retournent « Aucun résultat » ou « Échec » si l’authentification échoue.
  • Ont des méthodes pour les actions de demande et d’interdiction quand des utilisateurs tentent d’accéder à des ressources :
    • Ils ne sont pas autorisés à accéder (interdiction).
    • Quand ils ne sont pas authentifiés (demande).

Comparaison de RemoteAuthenticationHandler<TOptions> et de AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> est la classe pour l’authentification qui nécessite une étape d’authentification à distance. Une fois l’étape d’authentification distante terminée, le gestionnaire revient au CallbackPath défini par le gestionnaire. Le gestionnaire termine l’étape d’authentification en utilisant les informations passées au chemin du rappel de HandleRemoteAuthenticateAsync. OAuth 2.0 et OIDC utilisent tous deux ce modèle. JWT et les cookies ne l’utilisent pas, car ils peuvent utiliser directement l’en-tête du porteur et le cookie pour s’authentifier. Dans ce cas, le fournisseur hébergé à distance :

  • Est le fournisseur d’authentification.
  • Il s’agit par exemple de Facebook, Twitter, Google, Microsoft et tout autre fournisseur OIDC qui gère l’authentification des utilisateurs en utilisant le mécanisme des gestionnaires.

Authentifier

L’action d’authentification d’un schéma d’authentification est responsable de la construction de l’identity de l’utilisateur en fonction du contexte de la demande. Elle retourne un AuthenticateResult indiquant si l’authentification a réussi et, le cas échéant, l’identity de l’utilisateur dans un ticket d’authentification. Consultez AuthenticateAsync. Voici des exemples d’authentification :

  • Un schéma d’authentification de cookie qui construit l’identity de l’utilisateur à partir des cookies
  • Un schéma de porteur JWT désérialisant et validant un jeton de porteur JWT pour construire l’identity de l’utilisateur

Défi

Une demande d’authentification est appelée par l’autorisation quand un utilisateur non authentifié demande un point de terminaison qui nécessite une authentification. Une demande d’authentification est émise, par exemple quand un utilisateur anonyme demande une ressource restreinte ou suit un lien de connexion. L’autorisation appelle une demande en utilisant le ou les schémas d’authentification spécifiés, ou le schéma par défaut si aucun schéma n’est spécifié. Consultez ChallengeAsync. Voici des exemples de demande d’authentification :

  • Un schéma d’authentification de cookie redirigeant l’utilisateur vers une page de connexion.
  • Un schéma de porteur JWT retournant un résultat 401 avec un en-tête www-authenticate: bearer.

Une action de demande doit indiquer à l’utilisateur quel mécanisme d’authentification utiliser pour accéder à la ressource demandée.

Interdiction

Une action d’interdiction d’un schéma d’authentification est appelée par l’autorisation quand un utilisateur authentifié tente d’accéder à une ressource à laquelle il n’est pas autorisé à accéder. Consultez ForbidAsync. Voici des exemples d’interdiction d’authentification :

  • Un schéma d’authentification de cookie redirigeant l’utilisateur vers une page indiquant que l’accès a été interdit.
  • Un schéma de porteur JWT retournant un résultat 403.
  • Un schéma d’authentification personnalisé redirigeant vers une page où l’utilisateur peut demander l’accès à la ressource.

Une action d’interdiction peut indiquer à l’utilisateur que :

  • Il est authentifié.
  • Il n’est pas autorisé à accéder à la ressource demandée.

Consultez les liens suivants pour connaître les différences entre la demande et l’interdiction :

Fournisseurs d’authentification par locataire

ASP.NET Core n’a pas de solution intégrée pour l’authentification multilocataire. Bien qu’il soit possible pour les clients d’en écrire une en utilisant les fonctionnalités intégrées, nous vous recommandons de considérer Orchard Core, ABP Framework ou Finbuckle.MultiTenant pour l’authentification multilocataire.

Orchard Core est :

  • Un framework d’application open source, modulaire et multilocataire créé avec ASP.NET Core.
  • Un système de gestion de contenu (CMS) basé sur ce framework d’application.

Consultez la source d’Orchard Core pour obtenir un exemple de fournisseurs d’authentification par locataire.

ABP Framework prend en charge différents modèles d’architecture, notamment la modularité, les microservices, la conception pilotée par le domaine et le multilocataire. Consultez la source d’ABP Framework sur GitHub.

Finbuckle.MultiTenant :

  • Open source
  • Fournit une résolution de locataire
  • Légèreté
  • Fournit une isolation des données
  • Configurer le comportement de l’application de manière unique pour chaque locataire

Ressources supplémentaires

Par Mike Rousos

L’authentification est le processus de détermination de l’identity d’un utilisateur. L’autorisation est le processus consistant à déterminer si un utilisateur a accès à une ressource. Dans ASP.NET Core, l’authentification est gérée par le service d’authentification, IAuthenticationService, qui est utilisé par l’intergiciel (middleware) d’authentification. Le service d’authentification utilise des gestionnaires d’authentification inscrits pour effectuer des actions liées à l’authentification. Voici des exemples d’actions liées à l’authentification :

  • Authentifier un utilisateur.
  • Répondre quand un utilisateur non authentifié tente d’accéder à une ressource restreinte.

Les gestionnaires d’authentification inscrits et leurs options de configuration sont appelés « schémas ».

Les schémas d’authentification sont spécifiés en inscrivant les services d’authentification dans Program.cs :

Par exemple, le code suivant inscrit les services et les gestionnaires d’authentification pour les schémas d’authentification de cookie et de porteur JWT :

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("CookieSettings", options));

Le paramètre JwtBearerDefaults.AuthenticationScheme de AddAuthentication est le nom du schéma à utiliser par défaut quand un schéma spécifique n’est pas demandé.

Si plusieurs schémas sont utilisés, les stratégies d’autorisation (ou les attributs d’autorisation) peuvent spécifier le ou les schémas d’authentification dont elles dépendent pour authentifier l’utilisateur. Dans l’exemple ci-dessus, le schéma d’authentification cookie peut être utilisé en spécifiant son nom (CookieAuthenticationDefaults.AuthenticationScheme par défaut, bien qu’un autre nom puisse être fourni lors de l’appel de AddCookie).

Dans certains cas, l’appel à AddAuthentication est effectué automatiquement par d’autres méthodes d’extension. Par exemple, lors de l’utilisation de ASP.NET Core Identity, AddAuthentication est appelé en interne.

L’intergiciel d’authentification est ajouté dans Program.cs en appelant UseAuthentication. L’appel de UseAuthentication inscrit le middleware qui utilise les schémas d’authentification précédemment inscrits. Appelez UseAuthentication avant tout middleware dépendant de l’authentification des utilisateurs.

Concepts d’authentification

L’authentification doit fournir le ClaimsPrincipal pour que l’automatiquement puisse prendre des décisions d’autorisation en fonction de celui-ci. Il existe plusieurs approches des schémas d’authentification pour sélectionner le gestionnaire d’authentification responsable de la génération de l’ensemble correct de revendications :

Il n’y a pas de détection automatique des schémas. Si le schéma par défaut n’est pas spécifié, le schéma doit être spécifié dans l’attribut d’autorisation ; sinon, l’erreur suivante est levée :

InvalidOperationException : Aucun authenticationScheme n’a été spécifié et aucun DefaultAuthenticateScheme n’a été trouvé. Les schémas par défaut peuvent être définis en utilisant AddAuthentication(string defaultScheme) ou AddAuthentication(Action<options_authentification> configureOptions).

Schéma d’authentification

Le schéma d’authentification peut sélectionner le gestionnaire d’authentification responsable de la génération de l’ensemble correct de revendications. Pour plus d’informations, consultez Autoriser avec un schéma spécifique.

Un schéma d’authentification est un nom qui correspond à :

  • Un gestionnaire d’authentification.
  • Des options pour la configuration de cette instance spécifique du gestionnaire.

Les schémas sont utiles comme mécanisme pour faire référence au comportement d’authentification, de demande et d’interdiction du gestionnaire associé. Par exemple, une stratégie d’autorisation peut utiliser des noms de schéma pour spécifier le ou les schémas d’authentification à utiliser pour authentifier l’utilisateur. Lors de la configuration de l’authentification, il est courant de spécifier le schéma d’authentification par défaut. Le schéma par défaut est utilisé sauf si une ressource demande un schéma spécifique. Il est également possible de :

  • Spécifier différents schémas par défaut à utiliser pour les actions d’authentification, de demande et d’interdiction.
  • Combiner plusieurs schémas en un seul en utilisant des schémas de stratégie.

Gestionnaire d’authentification

Un gestionnaire d’authentification :

En fonction de la configuration du schéma d’authentification et du contexte de la demande entrante, les gestionnaires d’authentification :

  • Construisent des objets AuthenticationTicket représentant l’identity de l’utilisateur si l’authentification réussit
  • Retournent « Aucun résultat » ou « Échec » si l’authentification échoue.
  • Ont des méthodes pour les actions de demande et d’interdiction quand des utilisateurs tentent d’accéder à des ressources :
    • Ils ne sont pas autorisés à accéder (interdiction).
    • Quand ils ne sont pas authentifiés (demande).

Comparaison de RemoteAuthenticationHandler<TOptions> et de AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> est la classe pour l’authentification qui nécessite une étape d’authentification à distance. Une fois l’étape d’authentification distante terminée, le gestionnaire revient au CallbackPath défini par le gestionnaire. Le gestionnaire termine l’étape d’authentification en utilisant les informations passées au chemin du rappel de HandleRemoteAuthenticateAsync. OAuth 2.0 et OIDC utilisent tous deux ce modèle. JWT et les cookies ne l’utilisent pas, car ils peuvent utiliser directement l’en-tête du porteur et le cookie pour s’authentifier. Dans ce cas, le fournisseur hébergé à distance :

  • Est le fournisseur d’authentification.
  • Il s’agit par exemple de Facebook, Twitter, Google, Microsoft et tout autre fournisseur OIDC qui gère l’authentification des utilisateurs en utilisant le mécanisme des gestionnaires.

Authentifier

L’action d’authentification d’un schéma d’authentification est responsable de la construction de l’identity de l’utilisateur en fonction du contexte de la demande. Elle retourne un AuthenticateResult indiquant si l’authentification a réussi et, le cas échéant, l’identity de l’utilisateur dans un ticket d’authentification. Consultez AuthenticateAsync. Voici des exemples d’authentification :

  • Un schéma d’authentification de cookie qui construit l’identity de l’utilisateur à partir des cookies
  • Un schéma de porteur JWT désérialisant et validant un jeton de porteur JWT pour construire l’identity de l’utilisateur

Défi

Une demande d’authentification est appelée par l’autorisation quand un utilisateur non authentifié demande un point de terminaison qui nécessite une authentification. Une demande d’authentification est émise, par exemple quand un utilisateur anonyme demande une ressource restreinte ou suit un lien de connexion. L’autorisation appelle une demande en utilisant le ou les schémas d’authentification spécifiés, ou le schéma par défaut si aucun schéma n’est spécifié. Consultez ChallengeAsync. Voici des exemples de demande d’authentification :

  • Un schéma d’authentification de cookie redirigeant l’utilisateur vers une page de connexion.
  • Un schéma de porteur JWT retournant un résultat 401 avec un en-tête www-authenticate: bearer.

Une action de demande doit indiquer à l’utilisateur quel mécanisme d’authentification utiliser pour accéder à la ressource demandée.

Interdiction

Une action d’interdiction d’un schéma d’authentification est appelée par l’autorisation quand un utilisateur authentifié tente d’accéder à une ressource à laquelle il n’est pas autorisé à accéder. Consultez ForbidAsync. Voici des exemples d’interdiction d’authentification :

  • Un schéma d’authentification de cookie redirigeant l’utilisateur vers une page indiquant que l’accès a été interdit.
  • Un schéma de porteur JWT retournant un résultat 403.
  • Un schéma d’authentification personnalisé redirigeant vers une page où l’utilisateur peut demander l’accès à la ressource.

Une action d’interdiction peut indiquer à l’utilisateur que :

  • Il est authentifié.
  • Il n’est pas autorisé à accéder à la ressource demandée.

Consultez les liens suivants pour connaître les différences entre la demande et l’interdiction :

Fournisseurs d’authentification par locataire

ASP.NET Core n’a pas de solution intégrée pour l’authentification multilocataire. Bien qu’il soit possible pour les clients d’en écrire une en utilisant les fonctionnalités intégrées, nous vous recommandons de considérer Orchard Core ou ABP Framework pour l’authentification multilocataire.

Orchard Core est :

  • Un framework d’application open source, modulaire et multilocataire créé avec ASP.NET Core.
  • Un système de gestion de contenu (CMS) basé sur ce framework d’application.

Consultez la source d’Orchard Core pour obtenir un exemple de fournisseurs d’authentification par locataire.

ABP Framework prend en charge différents modèles d’architecture, notamment la modularité, les microservices, la conception pilotée par le domaine et le multilocataire. Consultez la source d’ABP Framework sur GitHub.

Ressources supplémentaires

Par Mike Rousos

L’authentification est le processus de détermination de l’identity d’un utilisateur. L’autorisation est le processus consistant à déterminer si un utilisateur a accès à une ressource. Dans ASP.NET Core, l’authentification est gérée par le service d’authentification, IAuthenticationService, qui est utilisé par l’intergiciel (middleware) d’authentification. Le service d’authentification utilise des gestionnaires d’authentification inscrits pour effectuer des actions liées à l’authentification. Voici des exemples d’actions liées à l’authentification :

  • Authentifier un utilisateur.
  • Répondre quand un utilisateur non authentifié tente d’accéder à une ressource restreinte.

Les gestionnaires d’authentification inscrits et leurs options de configuration sont appelés « schémas ».

Les schémas d’authentification sont spécifiés en inscrivant les services d’authentification dans Startup.ConfigureServices :

  • En appelant une méthode d’extension spécifique à un schéma après un appel à AddAuthentication (comme par exemple AddJwtBearer ou AddCookie). Ces méthodes d’extension utilisent AuthenticationBuilder.AddScheme pour inscrire des schémas avec les paramètres appropriés.
  • Moins souvent, en appelant AuthenticationBuilder.AddScheme directement.

Par exemple, le code suivant inscrit les services et les gestionnaires d’authentification pour les schémas d’authentification de cookie et de porteur JWT :

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => Configuration.Bind("CookieSettings", options));

Le paramètre JwtBearerDefaults.AuthenticationScheme de AddAuthentication est le nom du schéma à utiliser par défaut quand un schéma spécifique n’est pas demandé.

Si plusieurs schémas sont utilisés, les stratégies d’autorisation (ou les attributs d’autorisation) peuvent spécifier le ou les schémas d’authentification dont elles dépendent pour authentifier l’utilisateur. Dans l’exemple ci-dessus, le schéma d’authentification cookie peut être utilisé en spécifiant son nom (CookieAuthenticationDefaults.AuthenticationScheme par défaut, bien qu’un autre nom puisse être fourni lors de l’appel de AddCookie).

Dans certains cas, l’appel à AddAuthentication est effectué automatiquement par d’autres méthodes d’extension. Par exemple, lors de l’utilisation de ASP.NET Core Identity, AddAuthentication est appelé en interne.

L’intergiciel d’authentification est ajouté dans Startup.Configure en appelant UseAuthentication. L’appel de UseAuthentication inscrit le middleware qui utilise les schémas d’authentification précédemment inscrits. Appelez UseAuthentication avant tout middleware dépendant de l’authentification des utilisateurs. Lors de l’utilisation du routage de point de terminaison, l’appel à UseAuthentication doit être :

  • Après UseRouting, afin que les informations de routage soient disponibles pour les décisions d’authentification.
  • Avant UseEndpoints, afin que les utilisateurs soient authentifiés avant d’accéder aux points de terminaison.

Concepts d’authentification

L’authentification doit fournir le ClaimsPrincipal pour que l’automatiquement puisse prendre des décisions d’autorisation en fonction de celui-ci. Il existe plusieurs approches des schémas d’authentification pour sélectionner le gestionnaire d’authentification responsable de la génération de l’ensemble correct de revendications :

Il n’y a pas de détection automatique des schémas. Si le schéma par défaut n’est pas spécifié, le schéma doit être spécifié dans l’attribut d’autorisation ; sinon, l’erreur suivante est levée :

InvalidOperationException : Aucun authenticationScheme n’a été spécifié et aucun DefaultAuthenticateScheme n’a été trouvé. Les schémas par défaut peuvent être définis en utilisant AddAuthentication(string defaultScheme) ou AddAuthentication(Action<options_authentification> configureOptions).

Schéma d’authentification

Le schéma d’authentification peut sélectionner le gestionnaire d’authentification responsable de la génération de l’ensemble correct de revendications. Pour plus d’informations, consultez Autoriser avec un schéma spécifique.

Un schéma d’authentification est un nom qui correspond à :

  • Un gestionnaire d’authentification.
  • Des options pour la configuration de cette instance spécifique du gestionnaire.

Les schémas sont utiles comme mécanisme pour faire référence au comportement d’authentification, de demande et d’interdiction du gestionnaire associé. Par exemple, une stratégie d’autorisation peut utiliser des noms de schéma pour spécifier le ou les schémas d’authentification à utiliser pour authentifier l’utilisateur. Lors de la configuration de l’authentification, il est courant de spécifier le schéma d’authentification par défaut. Le schéma par défaut est utilisé sauf si une ressource demande un schéma spécifique. Il est également possible de :

  • Spécifier différents schémas par défaut à utiliser pour les actions d’authentification, de demande et d’interdiction.
  • Combiner plusieurs schémas en un seul en utilisant des schémas de stratégie.

Gestionnaire d’authentification

Un gestionnaire d’authentification :

En fonction de la configuration du schéma d’authentification et du contexte de la demande entrante, les gestionnaires d’authentification :

  • Construisent des objets AuthenticationTicket représentant l’identity de l’utilisateur si l’authentification réussit
  • Retournent « Aucun résultat » ou « Échec » si l’authentification échoue.
  • Ont des méthodes pour les actions de demande et d’interdiction quand des utilisateurs tentent d’accéder à des ressources :
    • Ils ne sont pas autorisés à accéder (interdiction).
    • Quand ils ne sont pas authentifiés (demande).

Comparaison de RemoteAuthenticationHandler<TOptions> et de AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> est la classe pour l’authentification qui nécessite une étape d’authentification à distance. Une fois l’étape d’authentification distante terminée, le gestionnaire revient au CallbackPath défini par le gestionnaire. Le gestionnaire termine l’étape d’authentification en utilisant les informations passées au chemin du rappel de HandleRemoteAuthenticateAsync. OAuth 2.0 et OIDC utilisent tous deux ce modèle. JWT et les cookies ne l’utilisent pas, car ils peuvent utiliser directement l’en-tête du porteur et le cookie pour s’authentifier. Dans ce cas, le fournisseur hébergé à distance :

  • Est le fournisseur d’authentification.
  • Il s’agit par exemple de Facebook, Twitter, Google, Microsoft et tout autre fournisseur OIDC qui gère l’authentification des utilisateurs en utilisant le mécanisme des gestionnaires.

Authentifier

L’action d’authentification d’un schéma d’authentification est responsable de la construction de l’identity de l’utilisateur en fonction du contexte de la demande. Elle retourne un AuthenticateResult indiquant si l’authentification a réussi et, le cas échéant, l’identity de l’utilisateur dans un ticket d’authentification. Consultez AuthenticateAsync. Voici des exemples d’authentification :

  • Un schéma d’authentification de cookie qui construit l’identity de l’utilisateur à partir des cookies
  • Un schéma de porteur JWT désérialisant et validant un jeton de porteur JWT pour construire l’identity de l’utilisateur

Défi

Une demande d’authentification est appelée par l’autorisation quand un utilisateur non authentifié demande un point de terminaison qui nécessite une authentification. Une demande d’authentification est émise, par exemple quand un utilisateur anonyme demande une ressource restreinte ou suit un lien de connexion. L’autorisation appelle une demande en utilisant le ou les schémas d’authentification spécifiés, ou le schéma par défaut si aucun schéma n’est spécifié. Consultez ChallengeAsync. Voici des exemples de demande d’authentification :

  • Un schéma d’authentification de cookie redirigeant l’utilisateur vers une page de connexion.
  • Un schéma de porteur JWT retournant un résultat 401 avec un en-tête www-authenticate: bearer.

Une action de demande doit indiquer à l’utilisateur quel mécanisme d’authentification utiliser pour accéder à la ressource demandée.

Interdiction

Une action d’interdiction d’un schéma d’authentification est appelée par l’autorisation quand un utilisateur authentifié tente d’accéder à une ressource à laquelle il n’est pas autorisé à accéder. Consultez ForbidAsync. Voici des exemples d’interdiction d’authentification :

  • Un schéma d’authentification de cookie redirigeant l’utilisateur vers une page indiquant que l’accès a été interdit.
  • Un schéma de porteur JWT retournant un résultat 403.
  • Un schéma d’authentification personnalisé redirigeant vers une page où l’utilisateur peut demander l’accès à la ressource.

Une action d’interdiction peut indiquer à l’utilisateur que :

  • Il est authentifié.
  • Il n’est pas autorisé à accéder à la ressource demandée.

Consultez les liens suivants pour connaître les différences entre la demande et l’interdiction :

Fournisseurs d’authentification par locataire

Le framework ASP.NET Core n’a pas de solution intégrée pour l’authentification multilocataire. Bien qu’il soit possible pour les clients d’écrire une application avec une authentification multilocataire, nous vous recommandons d’utiliser un des frameworks d’application ASP.NET Core suivants qui prennent en charge l’authentification multilocataire :

Orchard Core

Orchard Core. Consultez la source d’Orchard Core pour obtenir un exemple de fournisseurs d’authentification par locataire.

ABP Framework

ABP Framework prend en charge différents modèles d’architecture, notamment la modularité, les microservices, la conception pilotée par le domaine et le multilocataire. Consultez la source d’ABP Framework sur GitHub.

Ressources supplémentaires