Cadre d'autorisation OAuth 2.0

Découvrez comment Auth0 fonctionne avec le cadre d’autorisation OAuth 2.0.

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é.

OAuth

introduit une couche d’autorisation et sépare le rôle de l’application de celui du

propriétaire de la ressource

. 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

serveur de ressources

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

jeton d’accès

— 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

serveur d’autorisation

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.

• Flux du code d’autorisation : utilisé par les applications Web exécutées sur un serveur. Il est également utilisé par les applications mobiles au moyen de la technique Proof Key for Code Exchange (PKCE).
• Flux implicite avec envoi de formulaire : utilisé par les applications axées sur JavaScript (applications monopages) exécutées dans le navigateur de l’utilisateur.
• Flux avec mot de passe du propriétaire de la ressource : utilisé par les applications hautement fiables.
• Flux des informations d’identification de l’application : utilisé pour les communications de machine à machine.

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 :

Paramètre	Description
response_type	Indique au serveur d’autorisation quel type d’octroi exécuter.
response_mode	(Facultatif) Indique comment le résultat de la requête d’autorisation est mis en forme. Valeurs : - query : pour l’octroi de code d’autorisation. 302 Found déclenche une redirection. - fragment : pour l’octroi implicite. 302 Found déclenche une redirection. - form_post : 200 OK avec les paramètres de réponse intégrés à un formulaire HTML comme paramètres caché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 délimité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 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 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 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é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 JWT 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 jeton d’identité.

Un jeton d’identité 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 l’octroi de code d’autorisation. Une réponse réussie est 302 Found, ce qui déclenche une redirection vers le redirect_uri. Les paramètres de réponse sont inclus dans 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 l’octroi implicite. Une réponse réussie est 302 Found, ce qui déclenche une redirection vers le redirect_uri (qui est un paramètre de la requête). Les paramètres de réponse sont inclus dans 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 à un formulaire HTML en tant que paramètres masqués. L’attribut 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 transmettre la réponse d’autorisation depuis le point de terminaison /authorization. Cela est particulièrement utile lorsque vous utilisez 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 dans 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, 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

• Prévenez les attaques et redirigez les utilisateurs à l’aide des paramètres state d’OAuth 2.0
• Quel flux OAuth 2.0 devrais-je utiliser ?