.AddOAuth() vs .AddOpenIdConnect()

Question

Les gens,

Pouvez-vous me préciser la différence et le but de ces deux méthodes ?

1. Microsoft.Extensions.DependencyInjection.OAuthExtensions.AddOAuth() ;
2. Microsoft.Extensions.DependencyInjection.OpenIdConnectExtensions.AddOpenIdConnect().

Selon le nom, l'un est utilisé pour autoriser, l'autre pour authentifier l'utilisateur, n'est-ce pas ? Donc si mon application mvc a besoin de savoir qui est l'utilisateur, je dois utiliser .AddOpenIdConnect() pour aller chercher id_token ? Et si j'ai besoin d'appeler le service de ressources depuis l'application mvc pour le compte de l'utilisateur actuel, je dois ajouter .AddOAuth() pour obtenir access_token ?

Des expériences avec auth0.com ont montré que le code avec .AddOAuth() est capable d'obtenir un jeton d'accès comme résultat de l'opération HttpContext.GetTokenAsync("access_token") mais rien si HttpContext.GetTokenAsync("id_token") .

Et vice-versa - .AddOpenIdConnect() peut obtenir id_token, mais pas access_token.

La configuration est la même pour les deux :

.AddOAuth("oauth", o =>
            {
                o.AuthorizationEndpoint = "https://<Realm>.auth0.com/authorize?audience=resourceAPI-server";
                o.TokenEndpoint = "https://<REALM>.auth0.com/oauth/token";
                o.ClientId = "<clientID>";
                o.ClientSecret = "<secret>";
                o.CallbackPath = "/cb_oauth";
                o.SaveTokens = true;

            })
            .AddOpenIdConnect("openIdConnect", o =>
            {
                o.Authority = "https://<REALM>.auth0.com";
                o.ClientId = "<clientID>";
                o.ClientSecret = "<secret>";
                o.CallbackPath = "/cb_openIdConnect";
                o.SaveTokens = true;
                o.Events =new OpenIdConnectEvents()
                {
                    OnRedirectToIdentityProvider = rc =>
                    {
                        rc.ProtocolMessage.SetParameter("audience","resourceAPI-server");
                        return Task.CompletedTask;
                    }
                };
            })

C'est vraiment étrange, car je peux obtenir les deux tokens (access et id) dans postman avec le flux de code et la portée. openid email profile .

Les tutoriels sur auth0.com montrent également que .AddOpenIdConnect() avec une portée supplémentaire peut également obtenir un jeton d'accès. C'est très déroutant.

Alors, lequel pour quel cas ?

Answer 1

Le site OAuth 2.0 Le cadre décrit des modèles généraux pour l'octroi d'autorisations, mais ne définit pas la manière de procéder à l'authentification.

OpenID Connect o OIDC est une extension OAuth qui ajoute et définit strictement un jeton d'identification pour renvoyer des informations sur l'utilisateur - est un profil de OAuth 2.0 qui définit un flux de travail pour l'authentification.

Donc si mon application mvc a besoin de savoir qui est l'utilisateur, je dois utiliser .AddOAuth().

La méthode recommandée est d'utiliser OIDC , OpenID connect vous donnera un jeton d'accès et un jeton d'identification. Le jeton d'identification est un JWT et contient des informations sur l'utilisateur authentifié. Votre application cliente validera le jeton, décodera le jeton pour obtenir les informations du profil de l'utilisateur à l'aide des éléments suivants AddOpenIdConnect extension .

Mais vous pouvez toujours utiliser AddOAuth La différence est qu'OAuth nécessite que vous obteniez un jeton d'accès de l'IDP pour accéder au point de terminaison de gestion des utilisateurs du fournisseur d'identité, qui renvoie les informations du profil de l'utilisateur.

Et si je dois appeler le service de ressources depuis l'application mvc au nom de l'utilisateur actuel, je dois ajouter AddOpenIdConnect() pour obtenir l'access_token ?

OIDC est une extension OAuth, vous pouvez donc utiliser l'une ou l'autre pour obtenir un jeton d'accès à une ressource protégée.

C'est vraiment étrange, car je peux obtenir les deux jetons (accès et identifiant) dans postman avec le flux de code et le profil email openid scope. De plus, les tutoriels sur auth0.com montrent que .AddOpenIdConnect() avec une portée supplémentaire peut également obtenir le jeton d'accès. Très déroutant.

openid email profile sont des champs d'application de l'OIDC . Si vous utilisez le flux de code, vous n'avez pas fourni votre champ d'application, seulement les champs d'application de l'OIDC, un jeton d'accès au porteur est également inclus. Cela permet de s'assurer que la réponse du jeton est conforme à la spécification OAuth 2.0. Pour les demandes d'authentification OpenID de base où seul un jeton d'identification est demandé, ce jeton d'accès est nominal et peut être ignoré sans risque. Le jeton d'accès entre toutefois en jeu lorsqu'on demande également l'accès aux données du profil de l'utilisateur au point de terminaison UserInfo.

Mais lorsque vous voulez acquérir un jeton d'accès pour accéder à une ressource/API protégée, vous devez enregistrer la ressource sur IDP(Auth0) et ajouter OIDC Scope, afin que Auth0 puisse demander le consentement de l'utilisateur pour obtenir le jeton d'accès.