Cadre d'autorisation OAuth 2.0

Découvrez comment Auth0 met en œuvre le cadre d’autorisation OAuth 2.0, y compris les types d’octroi pris en charge et les points de terminaison clés pour sécuriser vos API et vos applications.

Aperçu

Concepts clés

• Auth0 prend en charge le protocole OAuth 2.0 élaboré par l’Internet Engineering Task Force (IETF).
• Consultez la spécification OAuth 2.0 pour en savoir plus sur les rôles, les types d’octroi (ou workflows) et les points de terminaison.

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 à ses ressources protégées, sans nécessairement divulguer ses informations d’identification à long terme ni même son identité.

OAuth

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 se voit attribuer 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, le client obtient un

jeton d’accès

— une chaîne indiquant une portée spécifique, une durée de vie et d’autres attributs d’accès. Les jetons d’accès sont émis aux clients tiers par un

serveur d’autorisation

avec l’approbation du propriétaire de la ressource. Ensuite, le client utilise 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 autorisations représentées par le jeton d’accès, en termes OAuth, sont appelées scopes. Lorsqu’une application s’authentifie auprès d’Auth0, elle spécifie les scopes souhaités. 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 voulez accéder.
• Client : 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 nécessaire. Dans ce cas-ci, 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 situation dépend surtout du type d’application.

• Flux du code d’autorisation : utilisé par les applications Web exécutées sur un serveur. Ce flux est aussi utilisé par les applications mobiles au moyen de la technique de clé de preuve pour l’échange de code (PKCE).
• Flux implicite avec Form Post : utilisé par les applications axées sur JavaScript (applications monopage) qui s’exécutent dans le navigateur de l’utilisateur.
• Flux de mot de passe du propriétaire de la ressource : utilisé par les applications hautement fiables.
• Flux des informations d’identification du client : utilisé pour la communication machine à machine.

La spécification prévoit aussi 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 les situations où l’utiliser, consultez les flux d’authentification et d’autorisation.

​

Endpoints

OAuth 2.0 utilise deux endpoints : /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 voulez vous connecter à un service avec 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 demandera 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 :

Paramètre	Description
response_type	Indique au serveur d’autorisation quel grant exécuter.
response_mode	(Facultatif) Indique comment le résultat de la requête d’autorisation est mis en forme. Valeurs : - query : pour le grant Authorization Code. 302 Found déclenche une redirection. - fragment : pour le grant Implicit. 302 Found déclenche une redirection. - form_post : 200 OK avec les paramètres de réponse intégrés dans un formulaire HTML comme paramètres masqués. - web_message : pour l’authentification silencieuse. Utilise la messagerie Web HTML5.
client_id	L’ID de l’application qui demande l’autorisation.
redirect_uri	Contient une URL. Une réponse réussie de ce point de terminaison entraîne une redirection vers cette URL.
scope	Une liste de permissions séparées par des espaces dont l’application a besoin.
state	Une valeur opaque, utilisée à des fins de sécurité. Si ce paramètre de requête est défini dans la requête, il est renvoyé à l’application dans le cadre du redirect_uri.
connection	Spécifie le type de connexion pour les connexions Passwordless

Vous pouvez configurer des paramètres de requête personnalisés lorsque votre application effectue la requête initiale vers le 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 Universal Login.

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éfixés par ext- apparaissent automatiquement dans le contexte du modèle de page.

Ce point de terminaison est utilisé par les types de grant Authorization Code et Implicit. Le serveur d’autorisation doit savoir quel type de grant l’application veut utiliser, puisque cela influe sur le type d’identifiant qu’il émettra :

• Pour le grant Authorization Code, il émettra un code d’autorisation (qui pourra ensuite être échangé contre un jeton d’accès au point de terminaison /oauth/token).
• Pour le grant Implicit, il émettra un jeton d’accès, qui est une chaîne opaque (ou un JWT dans une mise en œuvre Auth0) qui indique quelle application a été autorisée à quelles permissions (scopes), et par qui.

Pour indiquer au serveur d’autorisation quel type de grant utiliser, le paramètre de requête response_type est utilisé comme suit :

• Pour le grant Authorization Code, utilisez response_type=code pour inclure le code d’autorisation.
• Pour le grant Implicit, utilisez response_type=token pour inclure un jeton d’accès. Une autre possibilité est d’utiliser response_type=id_token token pour inclure à la fois un jeton d’accès et un ID token.

Un ID token est un JWT qui contient des renseignements sur l’utilisateur connecté. Il a été introduit par OpenID 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 :

Valeur	Description
query	Il s’agit du mode par défaut pour le grant Authorization Code. Une réponse réussie est 302 Found, ce qui déclenche une redirection vers le redirect_uri. Les paramètres de la réponse sont intégrés à la composante de requête (la partie après ?) du redirect_uri dans l’en-tête Location. Par exemple : HTTP/1.1 302 Found Location: https://my-redirect-uri.callback?code=js89p2x1 où le code d’autorisation est js89p21.
fragment	Il s’agit du mode par défaut pour le grant Implicit. Une réponse réussie est 302 Found, ce qui déclenche une redirection vers le redirect_uri (qui est un paramètre de requête). Les paramètres de la réponse sont intégrés à la composante de fragment (la partie après #) du redirect_uri dans l’en-tête Location. Par exemple : HTTP/1.1 302 Found Location: https://my-redirect-uri/callback#access_token=eyB...78f&token_type=Bearer&expires_in=3600.
form_post	Le mode de réponse est défini par la spécification OAuth 2.0 Form Post Response Mode. Une réponse réussie est 200 OK et les paramètres sont intégrés dans un formulaire HTML sous forme de params masqués. L’élément action du formulaire correspond au redirect_uri et l’attribut onload est configuré pour soumettre le formulaire. Une fois le HTML chargé par le navigateur, une redirection vers le redirect_uri est effectuée.
web_message	Ce mode de réponse est défini dans la spécification OAuth 2.0 Web Message Response Mode. Il utilise la messagerie Web HTML5 au lieu d’une redirection pour la réponse d’autorisation provenant du point de terminaison /authorization. Cela est particulièrement utile lors de l’utilisation de l’authentification silencieuse. Pour utiliser ce mode de réponse, vous devez enregistrer l’URL de votre application dans le champ Allowed Web Origins des paramètres de l’application Auth0.

​

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 jeton d’actualisation. Il est utilisé dans tous les flux, sauf le flux implicite, car 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 du point de terminaison d’autorisation contre un jeton d’accès.
• Dans le flux des informations d’identification du client et l’échange d’octroi des informations d’identification par mot de passe du propriétaire de la ressource, l’application s’authentifie au moyen d’un ensemble d’informations d’identification, puis obtient un jeton d’accès.

​

Paramètres d’état

Les protocoles d’autorisation fournissent un paramètre state qui vous permet de rétablir l’état antérieur de votre application. Le paramètre state conserve l’objet d’état défini par le client dans la requête d’autorisation et le rend accessible au client dans la réponse. La principale raison d’utiliser le paramètre state est de réduire les risques d’attaques CSRF. Consultez Utiliser les paramètres d’état d’OAuth 2.0 pour en savoir plus.

​

En savoir plus

• Prévenir les attaques et rediriger les utilisateurs avec les paramètres d’état d’OAuth 2.0
• Quel flux OAuth 2.0 devrais-je utiliser ?