Appelez votre API à l’aide du Hybrid Flow

Découvrez comment exécuter le Hybrid Flow afin que votre application puisse utiliser un jeton d’identité pour accéder aux renseignements sur l’utilisateur, tout en obtenant un code d’autorisation pouvant être échangé contre un jeton d’accès.

Ce tutoriel vous aidera à appeler votre propre API à l’aide du Hybrid Flow. Si vous souhaitez comprendre le fonctionnement de ce flux et pourquoi vous devriez l’utiliser, consultez Hybrid Flow.

Auth0 facilite la mise en œuvre du flux de code d’autorisation dans votre application à l’aide de :

• API d’authentification : Si vous préférez créer votre propre solution, poursuivez votre lecture pour apprendre à appeler directement notre API.

​

Prérequis

Avant de commencer ce tutoriel :

• Enregistrez votre Application dans Auth0.

  • Sélectionnez le Type d’application approprié.
  • Ajoutez {https://yourApp/callback} comme URL de rappel autorisée.
  • Assurez-vous que les types d’octroi de votre Application incluent Implicit et Authorization Code. Pour savoir comment faire, consultez Mettre à jour les types d’octroi.
  • Si vous voulez que votre Application puisse utiliser des jetons d’actualisation, assurez-vous que les types d’octroi de l’Application incluent jeton d’actualisation. Pour savoir comment faire, consultez Mettre à jour les types d’octroi. Pour en savoir plus sur les jetons d’actualisation, consultez jetons d’actualisation.

• Enregistrez votre API dans Auth0

  • Si vous voulez que votre API reçoive des jetons d’actualisation afin d’obtenir de nouveaux jetons lorsque les précédents expirent, activez autoriser l’accès hors ligne.

​

Étapes

1. Autoriser l’utilisateur: Demandez l’autorisation de l’utilisateur, puis redirigez-le vers votre application avec un code d’autorisation.
2. Demander des jetons: Échangez votre code d’autorisation contre des jetons.
3. Appeler l’API: Utilisez le jeton d’accès obtenu pour appeler votre API.
4. Actualiser les jetons: Utilisez un jeton d’actualisation pour demander de nouveaux jetons lorsque les jetons actuels expirent.

Facultatif : Voir des exemples de cas d’utilisation

​

Autoriser l’utilisateur

Cette étape peut comprendre un ou plusieurs des processus suivants :

• Authentifier l’utilisateur
• Rediriger l’utilisateur vers un Identity Provider pour prendre en charge l’authentification
• Vérifier s’il existe des sessions d’authentification unique (SSO) actives
• Obtenir le consentement de l’utilisateur pour le niveau d’autorisation demandé, sauf si ce consentement a déjà été accordé.

Pour autoriser l’utilisateur, votre application doit rediriger l’utilisateur vers l’URL d’autorisation.

​

Exemple d’URL d’autorisation

Paramètres

Notez que pour autoriser un utilisateur lors d’une requête à une API personnalisée, vous :

• devez inclure un paramètre audience
• pouvez inclure des portées supplémentaires pris en charge par l’API cible

Nom du paramètre	Description
response_type	Indique le type d’informations d’authentification qu’Auth0 renverra (code ou token). Pour ce flux, la valeur doit inclure code, mais peut aussi inclure id_token, token ou id_token token. Plus précisément, id_token renvoie un ID Token, et token renvoie un jeton d’accès.
response_mode	Précise la façon dont les paramètres de réponse doivent être renvoyés. Pour des raisons de sécurité, la valeur devrait être form_post. Dans ce mode, les paramètres de réponse seront encodés comme des valeurs de formulaire HTML transmises au moyen de la méthode HTTP POST et encodées dans le corps à l’aide du format application/x-www-form-urlencoded.
client_id	Le ID client de votre application. Vous trouverez cette valeur dans vos paramètres de l’application.
redirect_uri	L’URL vers laquelle Auth0 redirigera le navigateur après que l’utilisateur aura accordé l’autorisation. Le code d’autorisation sera disponible dans le paramètre d’URL code. Vous devez indiquer cette URL comme URL de rappel valide dans vos paramètres de l’application. Avertissement : Conformément à la spécification OAuth 2.0, Auth0 supprime tout ce qui suit le hash et ne tient pas compte des fragments.
scope	Précise les portées pour lesquelles vous souhaitez demander une autorisation, ce qui détermine quelles claims (ou quels attributs utilisateur) vous voulez voir renvoyés. Ils doivent être séparés par un espace. Vous pouvez demander n’importe lequel des portées OpenID Connect (OIDC) standard concernant les utilisateurs, comme profile ou email, des custom claims conformes à un format namespaced, ou tout portée pris en charge par l’API cible (p. ex., read:contacts). Incluez offline_access pour obtenir un jeton d’actualisation (assurez-vous que le champ autoriser l’accès hors ligne est activé dans les paramètres de l’application).
audience	L’identifiant unique de l’API à laquelle votre application souhaite accéder. Utilisez la valeur Identifier dans l’onglet Settings de l’API que vous avez créée dans le cadre des prérequis de ce tutoriel.
state	(recommandé) Une chaîne alphanumérique opaque et arbitraire que votre application ajoute à la requête initiale et qu’Auth0 inclut lors de la redirection vers votre application. Pour savoir comment utiliser cette valeur afin de prévenir les attaques de falsification de requêtes intersites (CSRF), consultez Mitigate CSRF Attacks With State Parameters.
nonce	Une chaîne aléatoire cryptographiquement sûre que votre application ajoute à la requête initiale et qu’Auth0 inclut dans l’ID Token, utilisée pour prévenir les attaques par rejeu de jetons.
organization	(facultatif) ID de l’organisation à utiliser lors de l’authentification d’un utilisateur. S’il n’est pas fourni et que votre application est configurée pour Display Organization Prompt, l’utilisateur pourra saisir le nom de l’organisation lors de l’authentification.
invitation	(facultatif) ID du ticket d’invitation de l’organisation. Lors de l’invitation d’un membre à une Organization, votre application doit gérer l’acceptation de l’invitation en transmettant les paires clé-valeur invitation et organization lorsque l’utilisateur accepte l’invitation.

À titre d’exemple, votre extrait HTML pour votre URL d’autorisation lors de l’ajout de la fonctionnalité de connexion à votre application pourrait ressembler à ceci :

​

Réponse

Si tout se passe bien, vous recevrez une réponse HTTP 302. Les identifiants demandés sont encodés dans le corps :

HTTP/1.1 302 Found
Content-Type: application/x-www-form-urlencoded
code=AUTHORIZATION_CODE&
access_token=ey...MhPw
&expires_in=7200
&token_type=Bearer
id_token=eyJ...acA&
state=xyzABC123

Notez que les valeurs renvoyées dépendent du response_type que vous avez demandé.

Type de réponse	Composants
code	code d’autorisation
id_token	jeton d’identité
token	jeton d’accès (plus les valeurs expires_in et token_type)
id_token token	jeton d’identité, jeton d’accès (plus les valeurs expires_in et token_type)

Auth0 renverra également toute valeur state que vous avez incluse dans votre requête vers l’URL d’autorisation.

Le jeton d’accès que vous recevez dans cette transaction n’est que le premier jeton d’accès que vous recevrez. Nous ne recommandons pas de l’utiliser pour appeler des API.

Validez vos jetons avant de les enregistrer. Pour savoir comment faire, consultez Valider le jeton d’identité et Valider les jetons d’accès.

Lorsque vous décodez et analysez votre jeton d’identité, vous remarquerez une revendication supplémentaire, c_hash, qui contient un hachage du code. Cette revendication est obligatoire lorsqu’un jeton d’identité est émis en même temps qu’un code, et vous devez la valider :

1. À l’aide de l’algorithme de hachage indiqué dans la revendication alg de l’en-tête du jeton d’identité, calculez le hachage des octets de la représentation ASCII du code.
2. Encodez en Base64url la moitié gauche du hachage.
3. Vérifiez que le résultat correspond à la valeur c_hash.

​

Demander des jetons

Maintenant que vous avez un code d’autorisation, vous devez l’échanger contre des jetons. À l’aide du code d’autorisation (code) extrait à l’étape précédente, vous devrez envoyer une requête POST à l’URL de jeton.

Le jeton d’accès que vous recevez à cette étape est celui que vous devez utiliser pour effectuer des requêtes à votre API. Assurez-vous de le garder distinct du jeton d’accès que vous avez reçu à l’étape précédente de ce tutoriel.

​

Exemple de requête POST vers l’URL du jeton

Paramètres

Nom du paramètre	Description
grant_type	Définissez cette valeur sur authorization_code.
code	Le authorization_code récupéré à l’étape précédente de ce tutoriel.
client_id	L’ID client de votre application. Vous trouverez cette valeur dans les Paramètres de l’application.
client_secret	Le secret client de votre application. Vous trouverez cette valeur dans les Paramètres de l’application. Pour en savoir plus sur les méthodes d’authentification d’application disponibles, consultez Identifiants de l’application.
redirect_uri	L’URL de rappel valide définie dans les paramètres de votre application. Elle doit correspondre exactement au redirect_uri transmis à l’URL d’autorisation à l’étape précédente de ce tutoriel. Notez que cette valeur doit être encodée dans une URL.

​

Réponse

Si tout se passe bien, vous recevrez une réponse HTTP 200 avec un payload contenant les valeurs access_token, refresh_token, id_token et token_type :

{
  "access_token": "eyJz93a...k4laUWw",
  "refresh_token": "GEbRxBN...edjnXbL",
  "id_token": "eyJ0XAi...4faeEoQ",
  "token_type": "Bearer"
}

Validez vos jetons avant de les enregistrer. Pour savoir comment faire, consultez Valider les jetons d’identité et Valider les jetons d’accès.

Les jetons d’identité contiennent des renseignements sur l’utilisateur qui doivent être décodés et extraits.

Les jetons d’accès servent à effectuer une requête au point de terminaison /userinfo de l’API d’authentification Auth0 ou à une autre API. Si vous effectuez une requête à votre propre API, la première chose que votre API devra faire est de vérifier le jeton d’accès.

Les jetons d’actualisation servent à obtenir un nouveau jeton d’accès ou un nouveau jeton d’identité après l’expiration du précédent. Le refresh_token ne sera présent dans la réponse que si vous avez inclus la portée offline_access et activé Autoriser l’accès hors ligne pour votre API dans le Dashboard.

Les jetons d’actualisation doivent être stockés de manière sécuritaire, puisqu’ils permettent à un utilisateur de rester authentifié pratiquement indéfiniment.

​

Appeler l’API

Pour appeler votre API à partir d’une application Web classique (ou dans des cas semblables où les identifiants de l’application peuvent être stockés en toute sécurité), l’application doit transmettre le jeton d’accès récupéré en tant que jeton Bearer dans l’en-tête Authorization de votre requête HTTP.

​

Jetons d’actualisation

Vous avez déjà reçu un jeton d’actualisation si vous avez suivi ce tutoriel et effectué les étapes suivantes :

• configuré votre API pour autoriser l’accès hors ligne
• inclus la portée offline_access lorsque vous avez lancé la requête d’authentification par l’intermédiaire du point de terminaison authorize.

Vous pouvez utiliser le jeton d’actualisation pour obtenir un nouveau jeton d’accès. En général, un utilisateur n’a besoin d’un nouveau jeton d’accès qu’après l’expiration du précédent ou lors du premier accès à une nouvelle ressource. Il est déconseillé d’appeler le point de terminaison pour obtenir un nouveau jeton d’accès chaque fois que vous faites une requête à une API, et Auth0 applique des limites de débit qui restreignent le nombre de requêtes au point de terminaison pouvant être exécutées avec le même jeton à partir de la même adresse IP.

Pour actualiser votre jeton, faites une requête POST au point de terminaison /oauth/token dans l’API d’authentification, en utilisant grant_type=refresh_token.

​

Exemple de requête POST à l’URL du jeton

Paramètres

Nom du paramètre	Description
grant_type	Définissez ce paramètre sur refresh_token.
client_id	Le ID client de votre application. Vous trouverez cette valeur dans les paramètres de l’application.
refresh_token	Le jeton d’actualisation à utiliser.
scope	(facultatif) Liste des portées demandées, séparées par des espaces. Si elle n’est pas envoyée, les portées d’origine seront utilisées; sinon, vous pouvez demander un sous-ensemble réduit de portées. Notez que cette valeur doit être encodée dans l’URL.

​

Réponse

Si tout se passe bien, vous recevrez une réponse HTTP 200 avec une charge utile contenant un nouvel access_token, sa durée de validité en secondes (expires_in), les valeurs scope accordées et token_type. Si la portée du jeton initial comprenait openid, la réponse comprendra également un nouvel id_token :

{
  "access_token": "eyJ...MoQ",
  "expires_in": 86400,
  "scope": "openid offline_access",
  "id_token": "eyJ...0NE",
  "token_type": "Bearer"
}

Validez vos jetons avant de les enregistrer. Pour savoir comment faire, consultez valider le jeton d’identité et Valider les jetons d’accès.

​

Quelques cas d’utilisation

​

Personnaliser les jetons

Vous pouvez utiliser des Rules pour modifier les portées renvoyés dans les jetons d’accès et/ou ajouter des claims aux jetons d’accès et aux jetons d’ID. (Pour en savoir plus sur les Rules, consultez Auth0 Rules.) Pour ce faire, ajoutez la Rule suivante, qui s’exécutera après l’authentification de l’utilisateur :

exports.onExecutePostLogin = async (event, api) => {
  // Ajouter des revendications personnalisées au jeton d'accès et au jeton d'identité
  api.accessToken.setCustomClaim('https://foo/bar', 'value');
  api.idToken.setCustomClaim('https://fiz/baz', 'some other value');

  // Modifier la portée du jeton d'accès
  api.accessToken.addScope('foo');
  api.accessToken.addScope('bar');
};

Les portées seront disponibles dans le jeton une fois que toutes les règles auront été exécutées.

Auth0 renvoie les informations de profil dans un format structuré de claims, tel que défini par la spécification OpenID Connect (OIDC). Cela signifie que les claims personnalisés ajoutés aux ID tokens ou aux jetons d’accès doivent respecter les directives et les restrictions afin d’éviter de possibles collisions.

​

Pour en savoir plus

• Cadre d’autorisation OAuth 2.0
• Protocole OpenID Connect
• Jetons