Passer au contenu principal

Overview

Concepts clés
  • Auth0 prend en charge le protocole OAuth 2.0 rédigé par l’Internet Engineering Task Force (IETF).
  • Découvrez les rôles, les types d’octroi (ou flux) et les points de terminaison de la spécification OAuth 2.0.
Le cadre d’autorisation OAuth 2.0 est un protocole qui permet à un utilisateur d’accorder à un site Web ou à une application tiers l’accès aux ressources protégées de l’utilisateur, sans nécessairement révéler ses informations d’identification à long terme ni même son identité. introduit une couche d’autorisation et sépare le rôle de l’application de celui du . Dans OAuth, l’application demande l’accès aux ressources contrôlées par le propriétaire de la ressource et hébergées par le et reçoit un ensemble d’informations d’identification différent de celui du propriétaire de la ressource. Plutôt que d’utiliser les informations d’identification du propriétaire de la ressource pour accéder aux ressources protégées, l’application obtient un — une chaîne indiquant un scope particulier, une durée de vie et d’autres attributs d’accès. Les jetons d’accès sont émis aux applications tierces par un avec l’approbation du propriétaire de la ressource. L’application utilise ensuite le jeton d’accès pour accéder aux ressources protégées hébergées par le serveur de ressources. Auth0 génère des jetons d’accès pour les scénarios d’autorisation d’API, au format JSON web token (JWT). Les permissions représentées par le jeton d’accès, en termes OAuth, sont connues sous le nom de scopes. Lorsqu’une application s’authentifie auprès d’Auth0, elle spécifie les scopes qu’elle souhaite. Si ces scopes sont autorisés par l’utilisateur, le jeton d’accès représentera ces scopes autorisés.

​
Rôles

Un flux OAuth 2.0 comprend les rôles suivants :
  • Propriétaire de la ressource : Entité pouvant accorder l’accès à une ressource protégée. Il s’agit généralement de l’utilisateur final.
  • Serveur de ressources : Serveur qui héberge les ressources protégées. Il s’agit de l’API à laquelle vous souhaitez accéder.
  • Application : Application qui demande l’accès à une ressource protégée au nom du propriétaire de la ressource.
  • Serveur d’autorisation : Serveur qui authentifie le propriétaire de la ressource et émet des jetons d’accès après avoir obtenu l’autorisation appropriée. Dans ce cas, il s’agit d’Auth0.

​
Types d’octroi

OAuth 2.0 définit quatre flux permettant d’obtenir un jeton d’accès. Ces flux sont appelés des types d’octroi. Le choix de celui qui convient à votre cas dépend surtout de votre type d’application. La spécification fournit également un mécanisme d’extensibilité permettant de définir des types d’octroi supplémentaires. Pour en savoir plus sur le fonctionnement de chaque type d’octroi et sur le moment où il doit être utilisé, consultez Flux d’authentification et d’autorisation.

​
Points de terminaison

OAuth 2.0 utilise deux points de terminaison : /authorize et /oauth/token.

​
Point de terminaison d’autorisation

Le point de terminaison /authorize sert à interagir avec le propriétaire de la ressource et à obtenir l’autorisation d’accéder à la ressource protégée. Pour mieux comprendre, imaginez que vous souhaitez vous connecter à un service à l’aide de votre compte Google. D’abord, le service vous redirige vers Google afin de vous authentifier (si vous n’êtes pas déjà connecté), puis un écran de consentement s’affiche, où l’on vous demande d’autoriser le service à accéder à certaines de vos données (ressources protégées) ; par exemple, votre adresse de courriel et votre liste de contacts. Les paramètres de requête du point de terminaison /authorize sont les suivants : Vous pouvez configurer des paramètres de requête personnalisés lorsque votre application effectue l’appel initial au point de terminaison /authorize pour authentifier un utilisateur. Vous pouvez utiliser des paramètres de requête personnalisés pour fournir un contexte supplémentaire au modèle de page de l’expérience . Vous devez activer ID First pour utiliser le paramètre connection. Pour en savoir plus sur le paramètre connection et l’expérience Universal Login, consultez Passwordless for Universal Login. Les paramètres de requête précédés de ext- apparaissent automatiquement dans le contexte du modèle de page. Ce point de terminaison est utilisé par les types d’octroi de code d’autorisation et implicite. Le serveur d’autorisation doit savoir quel type d’octroi l’application veut utiliser, puisque cela influe sur le type de justificatif qu’il émettra :
  • Pour l’octroi de code d’autorisation, il émettra un code d’autorisation (qui pourra ensuite être échangé contre un jeton d’accès au point de terminaison /oauth/token).
  • Pour l’octroi implicite, il émettra un jeton d’accès, qui est une chaîne opaque (ou un dans une implémentation Auth0) qui indique qui a autorisé quelles permissions (scopes) à quelle application.
Pour indiquer au serveur d’autorisation quel type d’octroi utiliser, le paramètre de requête response_type est utilisé comme suit :
  • Pour l’octroi de code d’autorisation, utilisez response_type=code pour inclure le code d’autorisation.
  • Pour l’octroi implicite, utilisez response_type=token pour inclure un jeton d’accès. Une autre possibilité consiste à utiliser response_type=id_token token pour inclure à la fois un jeton d’accès et un .
Un jeton d’identité est un JWT qui contient des renseignements sur l’utilisateur connecté. Il a été introduit par Connect (OIDC). La spécification OAuth 2.0 Multiple Response Type Encoding Practices a ajouté un paramètre qui précise comment le résultat de la requête d’autorisation est mis en forme. Ce paramètre s’appelle response_mode. Il est facultatif et peut prendre les valeurs suivantes :

​
Point de terminaison de jeton

Le point de terminaison /oauth/token est utilisé par l’application pour obtenir un jeton d’accès ou un . Il est utilisé dans tous les flux, sauf le flux implicite, puisque dans ce cas, un jeton d’accès est émis directement.
  • Dans le flux de code d’autorisation, l’application échange le code d’autorisation obtenu auprès du point de terminaison d’autorisation contre un jeton d’accès.
  • Dans le flux d’identifiants du client et l’échange de subvention avec identifiants du mot de passe du propriétaire de la ressource, l’application s’authentifie à l’aide d’un ensemble d’identifiants, puis obtient un jeton d’accès.

​
Paramètres state

Les protocoles d’autorisation fournissent un paramètre state qui vous permet de restaurer l’état précédent de votre application. Le paramètre state conserve un objet d’état défini par l’application dans la requête d’autorisation et le rend accessible à l’application dans la réponse. La principale raison d’utiliser le paramètre state est d’atténuer les attaques CSRF. Consultez Utiliser les paramètres state d’OAuth 2.0 pour en savoir plus.

​
En savoir plus