Appeler votre API à l’aide du flux hybride

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.

​

Prérequis

Avant de commencer ce tutoriel :

• Enregistrez votre application auprès d’Auth0.

  • Sélectionnez le Type d’application approprié.
  • 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.

• Enregistrez votre application auprès d’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 et redirigez-le vers votre application à l’aide d’un code d’autorisation.
2. Demande de jetons : Échange d’un code d’autorisation contre des jetons.
3. Appel d’API : Servez-vous du jeton d’accès récupéré pour appeler votre API.
4. Jetons d’actualisation : Utilisez un jeton d’actualisation pour demander de nouveaux jetons lorsque les jetons existants expirent.

Facultatif : Découvrez des cas d’utilisation

​

Autoriser l’utilisateur

Cette étape peut comprendre un ou plusieurs des procédés suivant :

• Authentifier l’utilisateur
• Redirection de l’utilisateur vers un fournisseur d’identité pour gérer l’authentification
• Vérification des sessions actives d’authentification unique (SSO)
• Obtenir le consentement de l’utilisateur pour le niveau de permission demandé, sauf si obtenu précédemment.

Pour autoriser l’utilisateur, votre application doit envoyer l’utilisateur à l’URL d’autorisation.

​

Exemple d’URL d’autorisation

https://{yourDomain}/authorize?
    response_type=YOUR_RESPONSE_TYPE&
    response_mode=form_post&
    client_id={yourClientId}&
    redirect_uri={https://yourApp/callback}&
    scope=SCOPE&
    audience=API_AUDIENCE&
    state=STATE&
    nonce=NONCE

Paramètres

Notez que pour autoriser un utilisateur lors de l’appel d’une API personnalisée, vous :

• devez inclure un paramètre d’audience
• 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
client_id	L’ID client de votre application. Vous pouvez trouver cette valeur dans les paramètres de l’application.
redirect_uri	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 /&gt ; <br /&gt ; 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&gt ; (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.
nonce	Une chaîne cryptographiquement aléatoire que votre application ajoute à la requête initiale et qu’Auth0 inclut dans le jeton d’ID, utilisée pour prévenir les attaques par réinsertion de jeton.
organization	(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 :

<a href="https://{yourDomain}/authorize?
  response_type=code id_token token&
  client_id={yourClientId}&
  redirect_uri={https://yourApp/callback}&  
  scope=appointments%20contacts&
  audience=appointments:api&
  state=xyzABC123&
  nonce=eq...hPmz">
  Sign In
</a>

​

Réponse

Si tout se passe bien, vous recevrez une réponse HTTP 302. Les informations d’identification demandées sont codées dans le corps du texte :

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

Validez vos jetons avant de les enregistrer. Pour en savoir plus, lisez Valider les jetons d’ID et Valider les jetons d’accès.

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 :

1. À 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.
2. Base64url code la moitié la plus à 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’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.

​

Exemple de POST à une URL de jeton

cURL

curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=authorization_code \
  --data 'client_id={yourClientId}' \
  --data 'client_secret={yourClientSecret}' \
  --data 'code=yourAuthorizationCode}' \
  --data 'redirect_uri={https://yourApp/callback}'

Paramètres

Nom de paramètres	Description
grant_type	Définir sur authorization_code.
code	authorization_code récupéré à l’étape précédente de ce tutoriel.
client_id	L’ID client de votre application. Vous pouvez trouver cette valeur dans les paramètres de votre application.
client_secret	Le secret client de votre application. Vous pouvez trouver cette valeur dans les paramètres de votre application. Pour en savoir plus sur les méthodes d’authentification d’application disponibles, lisez Identifiants d’applications.
redirect_uri	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.

​

Réponse

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 :

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

Validez vos jetons avant de les enregistrer. Pour en savoir plus, lisez Valider les jetons d’ID et Valider les jetons d’accès.

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.

​

Appeler l’API

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.

cURL

curl --request GET \
  --url https://myapi.com/api \
  --header 'authorization: Bearer {accessToken}' \
  --header 'content-type: application/json'

​

Jetons d’actualisation

Vous avez déjà reçu un jeton d’actualisation si vous avez suivi ce tutoriel et complété ce qui suit :

• configuré votre API pour autoriser l’accès hors ligne
• inclus la permission offline_access lorsque vous avez lancé la demande d’authentification via le point de terminaison d’autorisation.

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.

​

Exemple de POST à une URL de jeton

cURL

curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=refresh_token \
  --data 'client_id={yourClientId}' \
  --data 'refresh_token={yourRefreshToken}'

Paramètres

Nom du paramètre	Description
grant_type	Définir ce paramètre à refresh_token.
client_id	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.

​

Réponse

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 :

{
  "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 en savoir plus, lisez Valider les jetons d’ID et Valider les jetons d’accès.

​

Exemples de cas d’utilisation

​

Personnalisation des jetons

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 :

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.

​

En savoir plus

• Cadre d’applications Authorization OAuth 2.0
• Protocole OpenID Connect
• Jetons