Découvrez comment exécuter le flux hybride afin que votre application puisse utiliser un jeton d’ID pour accéder aux informations 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 flux Hybride. Pour en savoir plus sur le fonctionnement du flux et pourquoi l’utiliser, voir Flux hybride.
Auth0 permet à votre application d’implémenter facilement le flux de code d’autorisation en utilisant :
Authentication API : Si vous préférez créer votre propre solution, poursuivez la lecture pour savoir comment appeler notre API directement.
Ajoutez une URL de rappel autorisée de {https://yourApp/callback}.
Assurez-vous que les Types d’autorisation de votre application englobent Implicit (Implicite) et le code d’autorisation. Pour en savoir plus, lisez Mettre à jour les types d’autorisation.
Si vous souhaitez que votre application puisse utiliser des jetons d’actualisation, assurez-vous que les types d’autorisation de l’application comprennent le jeton d’actualisation. Pour en savoir plus, lisez Mettre à jour les types d’autorisation. Pour en savoir plus sur les jetons d’actualisation, lisez Jetons d’actualisation.
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.
Notez que pour autoriser un utilisateur lors de l’appel d’une API personnalisée, vous :
devez inclure un paramètre d’
pouvez inclure des permissions supplémentaires prises en charge par l’API cible
Nom du paramètre
Description
response_type
Indique le type d’identifiant qu’Auth0 va retourner (code ou jeton). Pour ce flux, la valeur doit inclure code, mais peut aussi inclure id_token, token, ou id_token token. Spécifiquement, id_token renvoie un jeton d’ID, et token renvoie un jeton d’accès.
response_mode
Spécifie la méthode avec laquelle les paramètres de réponse doivent être retournés. Pour des raisons de sécurité, la valeur doit être response_mode. Dans ce mode, les paramètres de réponse seront chiffrés comme des valeurs de formulaire HTML qui sont transmises via la méthode HTTP POST et chiffrées dans le corps en utilisant le format application/x-www-form-urlencoded
URL vers laquelle Auth0 redirigera le navigateur après que l’autorisation ait été accordée par l’utilisateur. Le code d’autorisation sera disponible dans le paramètre code de l’URL. Vous devez spécifier cette URL en tant qu’URL de rappel valide dans les paramètre de l’application. <br /> ; <br /> ; Attention: Conformément à la spécification OAuth 2.0, Auth0 supprime tout ce qui se trouve après le hachage et n’accepte pas les fragments.
scope
Indique les permissions pour lesquels vous souhaitez demander une autorisation, ce qui dicte les demandes (ou les attributs d’utilisateur) que vous souhaitez voir renvoyées. Ils doivent être séparés par un espace. Vous pouvez demander n’importe lequel des permissions standards d’OpenID Connect (OIDC) sur les utilisateurs, comme profile (profil) ou email (adresse courriel), des demandes personnalisées conformes à un format namespace, ou n’importe quelles permissions prises en charge par l’API cible (par exemple,read:contacts). Incluez offline_access pour obtenir un <dfn data-key=« refresh-token »>Jeton d’actualisation</dfn> ; (assurez-vous que le champ Allow Offline Access est activé dans les paramètres de l’application).
audience
L’identifiant unique de l’API à laquelle votre application veut accéder. Utilisez la valeur de l’identifiant dans l’onglet Settings(https://manage.auth0.com/#/apis) pour l’API que vous avez créée dans le cadre des prérequis de ce tutoriel.
state
(recommandé) Une chaîne alphanumérique arbitraire opaque que votre application ajoute à la requête initiale qu’Auth0 inclut lorsqu’elle redirige vers votre application. Pour voir comment utiliser cette valeur pour prévenir les attaques par falsification de requête intersites , voir la section Atténuer les attaques par falsification de requête intersites avec les paramètres d’état.
(facultatif) Identifiant de l’organisation à utiliser pour authentifier un utilisateur. S’il n’est pas fourni et que votre application est configurée pour afficher l’invite de l’organisation, l’utilisateur pourra entrer le nom de l’organisation lors de l’authentification.
invitation
(facultatif) Identifiant du ticket d’invitation de l’organisation. Lorsque vous invitez un membre à rejoindre une organisation, votre application doit gérer l’acceptation de l’invitation en transmettant les combinaisons de valeurs clés invitations et organization quand l’utilisateur accepte l’invitation.
Par exemple, votre code HTML pour l’URL d’autorisation lors de l’ajout d’une connexion à votre application pourrait ressembler à ceci :
Notez que les valeurs renvoyées dépendent de ce que vous avez demandé comme response_type.
Type de réponse
Composants
code
Code d’autorisation
id_token
Jeton d’ID
token
Jeton d’accès (et valeurs expires_in et token_type)
id_token token
Jeton d’ID, Jeton d’accès (et valeurs expires_in et token_type)
Auth0 renverra également toute valeur d’état que vous avez incluse dans votre appel à l’URL d’autorisation.
Le jeton d’accès que vous recevez dans le cadre de cette transaction n’est que le premier à vous être attribué. Nous vous déconseillons de l’utiliser pour appeler des API.
Lorsque vous décodez et analysez votre jeton d’ID, vous remarquerez une demande supplémentaire, c_hash, qui contient un hachage du code. Cette demande est obligatoire lorsqu’un jeton d’ID est émis en même temps qu’un code et que vous devez le valider :
À l’aide de l’algorithme de hachage spécifié dans la demande alg dans l’en-tête jeton d’ID, hachez les octets de la représentation ASCII du code.
Base64url code la moitié la plus à gauche du hachage.
Vérifiez que le résultat correspond à la valeur c_hash.
Maintenant que vous avez un code d’authentification, vous pouvez l’échanger pour des jetons. En utilisant le code d’autorisation (code) extrait de l’étape précédente, vous devrez POST sur l’URL du jeton.Le jeton d’accès que vous recevez à cette étape est celui que vous devez utiliser pour appeler votre API. Assurez-vous de le conserver séparément du jeton d’accès que vous avez reçu à l’étape précédente de ce tutoriel.
L’URL de rappel valide définie dans les paramètres de votre Application. Cela doit correspondre exactement à redirect_uri passé à l’ URL d’autorisation à l’étape précédente de ce tutoriel. Notez que cela doit être codé URL.
Si tout se passe bien, vous recevrez une réponse HTTP 200 avec une charge utile contenant les valeurs access_token, refresh_token, id_token ettoken_type :
Les Jetons d’ID contiennent des informations de l’utilisateur qui doivent être décodées et extraites.Les jetons d’accès sont utilisés pour appeler le point de terminaison /userinfo de l’Authentication API Auth0 ou une autre API. Si vous appelez 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 sont utilisés pour obtenir un nouveau jeton d’accès ou un nouveau jeton d’ID 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 permission offline_access et activé Autoriser l’accès hors ligne pour votre API dans le Dashboard.
Les jetons d’actualisation doivent être stockés en toute sécurité car ils permettent aux utilisateurs de rester authentifiés pratiquement indéfiniment.
Pour appeler votre API à partir d’une application Web standard (ou de cas similaires dans lesquels les informations d’identification de l’application peuvent être stockées en toute sécurité), l’application doit transmettre le jeton d’accès récupéré en tant que jeton du porteur dans l’en-tête d’autorisation de votre requête HTTP.
Vous pouvez utiliser le jeton d’actualisation pour obtenir le nouveau jeton d’accès. Généralement, un utilisateur aura besoin d’un nouveau jeton d’accès uniquement après l’expiration du précédent ou lorsqu’il accède à une nouvelle ressource pour la première fois. Il est déconseillé d’appeler le point de terminaison pour obtenir un nouveau jeton d’accès à chaque fois que vous appelez une API, et Auth0 impose des limites anti-attaques qui réduiront la quantité de requêtes au point de terminaison pouvant être exécutées en utilisant le même jeton depuis la même adresse IP.Pour actualiser votre jeton, effectuez une requête POST au point de terminaison /oauth/token dans l’Authentication API, à l’aide de grant_type=refresh_token.
L’ID client de votre application. Vous pouvez trouver cette valeur dans vos Paramètres d’application.
refresh_token
Le jeton d’actualisation à utiliser.
scope
(facultatif) Une liste délimitée par des espaces des permissions demandées. Si elle n’est pas envoyée, les permissions originales seront utilisées; sinon vous pouvez demander un ensemble réduit de permissions. Veuillez noter que cela doit être codé URL.
Si tout se passe bien, vous recevrez une réponse HTTP 200 avec une charge utile contenant un nouveau access_token, sa durée de vie en secondes (expires_in), les valeurs de permissions accordées et le token_type . Si la permission du jeton initial incluait openid, alors la réponse inclura également un nouveau id_token :
Vous pouvez utiliser des règles pour modifier les permissions renvoyées des jetons d’accès et/ou ajouter des demandes aux jetons d’accès et d’ID. (Pour en savoir plus sur les règles, lisez Règles d’Auth0.) Pour ce faire, ajoutez la règle suivante, qui s’exécutera après l’authentification de l’utilisateur :
Report incorrect code
Copy
Ask AI
exports.onExecutePostLogin = async (event, api) => { // Add custom claims to Access Token and ID Token api.accessToken.setCustomClaim('https://foo/bar', 'value'); api.idToken.setCustomClaim('https://fiz/baz', 'some other value'); // Modify the scope of the Access Token api.accessToken.addScope('foo'); api.accessToken.addScope('bar');};
Les permissions seront disponibles dans le jeton une fois toutes les règles exécutées.
Auth0 renvoie les informations de profil contenues dans un format de demande structuré tel que défini par la spécification OpenID Connect (OIDC). Cela signifie que les demandes personnalisées ajoutées aux jetons d’ID ou aux jetons d’accès doivent respecter des directives et des restrictions pour éviter d’éventuels conflits.
