Passer au contenu principal

Vue d’ensemble

Principaux concepts
  • Auth0 prend en charge le protocole OAuth 2.0 rédigé par l’IETF (Internet Engineering Task Force).
  • Découvrez les rôles, types d’autorisation (ou flux de production) et points de terminaison de la spécification OAuth 2.0.
Le cadre d’applications Authorization OAuth 2.0 est un protocole qui permet à un utilisateur d’accorder à un site Web ou à une application tierce l’accès aux ressources protégées de l’utilisateur, sans nécessairement révéler ses identifiants à long terme ou même son identité. introduit une couche d’autorisation et sépare le rôle du client de celui du propriétaire de la ressource. Dans OAuth, le client demande l’accès aux ressources contrôlées par le propriétaire de la ressource et hébergées par le serveur de ressources et reçoit un ensemble d’identifiants différent de celui du propriétaire de la ressource. Au lieu d’utiliser les identifiants du propriétaire de la ressource pour accéder aux ressources protégées, le client obtient un jeton d’accès, une chaîne indiquant une permission, une durée de vie et d’autres attributs d’accès spécifiques. Les jetons d’accès sont émis aux clients tiers par un serveur d’autorisation avec l’approbation du propriétaire de la ressource. Le client 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 jeton Web JSON (JWT). Les autorisations représentées par le jeton d’accès, dans la terminologie OAuth, sont connues sous le nom de permissions. Lorsqu’une application s’authentifie avec Auth0, elle spécifie les permissions qu’elle souhaite obtenir. Si ces permissions sont autorisées par l’utilisateur, le jeton d’accès les représentera.

​
Rôles

Un flux OAuth 2.0 comprend les rôles suivants :
  • (Propriétaire de ressource) : Une 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 hébergeant les ressources protégées. Il s’agit de l’API à laquelle vous souhaitez accéder.
  • Client : Application demandant l’accès à une ressource protégée au nom du propriétaire de ressource.
  • (Serveur d’autorisations) : 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, Auth0.

​
Types d’autorisation

OAuth 2.0 définit quatre flux pour obtenir un jeton d’accès. Ces flux sont appelés types d’autorisation. Le choix de la solution la plus adaptée à vos besoins dépend principalement du type d’application. La spécification OAuth 2.0 offre également un mécanisme d’extensibilité permettant de définir des types d’autorisations supplémentaires. Pour en savoir plus sur le fonctionnement de chaque type d’autorisation et sur le moment où il doit être utilisé, consultez Authentication and Authorization Flows (Flux d’authentification et d’autorisation).

​
Points de terminaison

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

​
Point de terminaison d’autorisation

Le point de terminaison /authorize est utilisé pour 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 souhaitiez vous connecter à un service en utilisant votre compte Google. Tout d’abord, le service vous redirige vers Google afin de vous authentifier (si vous n’êtes pas déjà connecté), puis vous obtenez un écran de consentement, dans lequel il vous est demandé d’autoriser le service à accéder à certaines de vos données (ressources protégées); par exemple, votre adresse 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 pour l’expérience de connexion universelle. Vous devez activer l’option ID First pour utiliser le paramètre connection. Pour plus d’informations sur le paramètre connection et l’expérience Connexion universelle, consultez Connexion universelle sans mot de passe. Les paramètres de requête précédés du préfixe ext- apparaissent automatiquement dans le contexte du modèle de page. Ce point de terminaison est utilisé par les types d’autorisation Code d’autorisation et Implicite. Le serveur d’autorisation doit savoir quel type d’octroi l’application souhaite utiliser, pour déterminer le type de justificatif à émettre :
  • Pour l’octroi d’un 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, 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 le type d’autorisation à utiliser, le paramètre de requête response_type est utilisé comme suit :
  • Pour l’octroi d’un 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 solution de rechange consiste à utiliser le jeton response_type=id_token pour inclure à la fois un jeton d’accès et un jeton d’ID.
Un jeton d’ID est un JWT qui contient des informations sur l’utilisateur connecté. Ce type de jeton a été introduit par Connect (OIDC). La spécification Pratiques d’encodage des types de réponses multiples OAuth 2.0 a ajouté un paramètre qui précise comment le résultat de la demande d’autorisation est formaté. Ce paramètre est appelé response_mode. Il est facultatif et peut avoir les valeurs suivantes :

​
Point de terminaison du jeton

Le point de terminaison /oauth/token est utilisé par l’application pour obtenir un jeton d’accès ou un jeton d’actualisation. Tous les flux l’utilisent, à l’exception du flux implicite, car dans ce cas, un jeton d’accès est émis directement.
  • Dans le flux du code d’autorisation, l’application échange le code d’autorisation qu’elle a obtenu du point de terminaison d’autorisation contre un jeton d’accès.
  • Dans le Flux des identifiants client et l’échange d’informations d’identification du mot de passe du propriétaire de ressource, l’application s’authentifie à l’aide d’un ensemble d’informations d’identification et obtient ensuite un jeton d’accès.

​
Paramètres d’état

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 le client dans la requête d’autorisation et le rend disponible pour le client dans la réponse. La principale raison d’utiliser le paramètre state est de réduire les attaques par falsification de requête intersite (CSRF). Consultez Use OAuth 2.0 State Parameters (Utiliser les paramètres d’état OAuth 2.0) pour plus de détails.

​
En savoir plus