Cadre d’applications Authorization OAuth 2.0

Overview

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

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 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 :

Resource Owner (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.
Resource Server (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.
Authorization Server (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.

Flux de code d’autorisation : utilisé par les applications Web s’exécutant sur un serveur. Il est également utilisé par les applications mobiles, à l’aide de la technique de Proof Key for Code Exchange (PKCE).
Flux implicite avec Form Post : utilisé par les applications centrées sur JavaScript (applications Web à page unique) qui s’exécutent sur le navigateur de l’utilisateur.
Flux de mot de passe du propriétaire de ressource : utilisé par les applications hautement fiables.
Flux des identifiants client : utilisé pour les communications entre machines.

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 :

Paramètre	Description
`response_type`	Indique au serveur d’autorisation quel type d’autorisation accorder.
`response_mode`	(facultatif) Comment est formaté le résultat de la requête d’autorisation. Valeurs : - `query` : pour l’octroi du code d’autorisation. `302 Found` déclenche une redirection. - `fragment` : pour un octroi implicite. `302 Found` déclenche une redirection. - `form_post` : `200 OK` avec des paramètres de réponse intégrés dans un formulaire HTML en tant que paramètres cachés. - `web_message` : Pour l’authentification silencieuse. Utilise la messagerie web HTML5.
`client_id`	L’identifiant de l’application qui demande l’autorisation.
`redirect_uri`	Contient une URL. Une réponse positive de ce point de terminaison entraîne une redirection vers cette URL.
`scope`	Une liste d’autorisations délimitées par des espaces dont a besoin l’application.
`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 en tant que partie du « redirect_uri ».
`connection`	Spécifie le type de connexion pour les connexions sans mot de passe

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 JWT 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 OpenID 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 :

Valeur	Description
`query`	C’est la valeur par défaut pour l’octroi du code d’autorisation. Une réponse réussie est `302 Found` qui déclenche une redirection vers le `redirect_uri`. Les paramètres de réponse sont intégrés dans le composant 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 de la valeur par défaut de l’autorisation implicite. Une réponse réussie est `302 Found`, qui déclenche une redirection vers le `redirect_uri` (qui est un paramètre de requête). Les paramètres de réponse sont intégrés dans le composant 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 en tant que paramètres dissimulés. L’action du formulaire est le `redirect_uri` et l’attribut `onload` est configuré pour soumettre le formulaire. Une fois que le HTML est chargé par le navigateur, une redirection vers le `redirect_uri` est effectuée.
`web_message`	Ce mode de réponse est défini dans Spécification du mode de réponse aux messages Web OAuth 2.0. Il utilise la messagerie Web HTML5 au lieu de la redirection pour la réponse d’autorisation du point de terminaison /authorization. Ceci 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 Origines Web autorisées de vos paramètres d’application Auth0.

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.

S’authentifier