Passer au contenu principal
Ce tutoriel vous aidera à appeler votre propre API à l’aide du flux de code d’autorisation. Si vous voulez comprendre comment ce flux fonctionne et pourquoi vous devriez l’utiliser, consultez Flux de code d’autorisation. Si vous voulez apprendre à ajouter la connexion à votre application Web régulière, consultez Ajouter la connexion à l’aide du flux de code d’autorisation.
Auth0 permet à votre application d’implémenter facilement le flux au moyen des options suivantes :

Prérequis

Avant de commencer ce tutoriel :

Étapes

Cette étape peut inclure un ou plusieurs des processus suivants :
  • Authentifier l’utilisateur
  • Rediriger l’utilisateur vers un fournisseur d’identité pour gérer 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é, à moins qu’il n’ait déjà été accordé.
Pour autoriser l’utilisateur, votre application doit l’envoyer vers l’URL d’autorisation.

Exemple d’URL d’autorisation

Paramètres
Notez que, pour autoriser un utilisateur lors de l’appel d’une API personnalisée, vous :
  • devez inclure un paramètre audience
  • pouvez inclure des scopes supplémentaires pris en charge par l’API cible
Nom du paramètreDescription
response_typeIndique le type de justificatif qu’Auth0 retournera (code ou token). Pour ce flux, la valeur doit être code.
client_idL’ID client de votre application. Vous pouvez trouver cette valeur dans les paramètres de l’application.
redirect_uriL’URL vers laquelle Auth0 redirigera le navigateur une fois l’autorisation accordée par l’utilisateur. Le code d’autorisation sera disponible dans le paramètre d’URL code. Vous devez spécifier cette URL comme URL de rappel valide dans les 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.
scopePrécise les scopes pour lesquels vous souhaitez demander une autorisation, et qui déterminent les claims (ou attributs utilisateur) que vous souhaitez obtenir en retour. Ils doivent être séparés par un espace. Vous pouvez demander n’importe lequel des scopes standards d’OpenID Connect (OIDC) concernant les utilisateurs, comme profile ou email, des claims personnalisées conformes à un format avec espace de noms, ou tout scope pris en charge par l’API cible (par exemple, read:contacts). Incluez offline_access pour obtenir un Jeton d’actualisation (assurez-vous que le champ Allow Offline Access est activé dans les paramètres de l’application).
audienceL’identifiant unique de l’API à laquelle votre application Web veut accéder. Utilisez la valeur Identifiant 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 arbitraire opaque 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ête intersite (CSRF), consultez Atténuer les attaques CSRF avec les paramètres state.
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 au moment de s’authentifier.
invitation(facultatif) ID du ticket d’invitation de l’organisation. Lorsque vous invitez un membre à une organisation, 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.
Par exemple, l’extrait HTML de votre URL d’autorisation pour ajouter la connexion à votre application pourrait ressembler à ceci :

Réponse

Si tout se passe bien, vous recevrez une réponse HTTP 302. Le code d’autorisation est inclus à la fin de l’URL :
HTTP/1.1 302 Found
Location: {https://yourApp/callback}?code={authorizationCode}&state=xyzABC123
Maintenant que vous disposez d’un Authorization Code, vous devez l’échanger contre des jetons. À l’aide de l’Authorization Code (code) extrait à l’étape précédente, vous devrez effectuer un POST vers l’URL du jeton.

Exemple de POST vers l’URL du jeton

Paramètres
Nom du paramètreDescription
grant_typeDéfinissez-la à authorization_code.
codeLe authorization_code obtenu à l’étape précédente de ce tutoriel.
client_idL’ID client de votre application. Vous pouvez trouver cette valeur dans les paramètres de l’application.
client_secretLe 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_uriL’URL de callback valide définie dans les paramètres de l’application. Elle doit correspondre exactement au redirect_uri envoyé à l’URL d’autorisation à l’étape précédente de ce tutoriel. Notez qu’elle doit être URL-encodée.

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 procéder, consultez Valider les ID Tokens et Valider les jetons d’accès.
Les ID tokens contiennent des informations sur l’utilisateur qui doivent être décodées et extraites.Les jetons d’accès servent à 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 permettent d’obtenir un nouveau jeton d’accès ou 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 le scope offline_access et activé Allow Offline Access pour votre API dans le Auth0 Dashboard.
Les jetons d’actualisation doivent être stockés de manière sécuritaire, puisqu’ils permettent à un utilisateur de demeurer authentifié pratiquement indéfiniment.
Pour appeler votre API à partir d’une Application Web régulière, l’application doit transmettre le jeton d’accès récupéré dans l’en-tête Authorization de votre requête HTTP, sous forme de Bearer Token.
Vous avez déjà reçu un jeton d’actualisation si vous avez suivi ce tutoriel et complété les étapes suivantes :
  • configuré votre API pour permettre l’accès hors ligne
  • inclus le scope offline_access lorsque vous avez lancé la requête d’authentification au moyen 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 l’endpoint pour obtenir un nouveau jeton d’accès à chaque appel d’API ; Auth0 applique des limites de débit qui restreignent le nombre de requêtes pouvant être exécutées vers l’endpoint avec le même jeton depuis la même adresse IP.Pour actualiser votre token, effectuez une requête POST au point de terminaison /oauth/token de l’Authentication API, avec grant_type=refresh_token.
Exemple de POST vers l’URL du jeton
Paramètres
Nom du paramètreDescription
grant_typeRéglez cette valeur sur refresh_token.
client_idL’ID client de votre application. Vous trouverez cette valeur dans les paramètres de l’application.
refresh_tokenLe jeton d’actualisation à utiliser.
scope(facultatif) Une liste de scopes demandés séparés par des espaces. S’il n’est pas envoyé, les scopes d’origine seront utilisés; sinon, vous pouvez demander un ensemble réduit de scopes. 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 un payload contenant un nouvel access_token, sa durée de vie en secondes (expires_in), les valeurs de scope octroyées et le token_type. Si le scope du jeton initial incluait openid, la réponse inclura é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 procéder, consultez Valider les ID Tokens et Valider les jetons d’accès.

Exemples de cas d’utilisation

Personnaliser les jetons

Vous pouvez utiliser les Actions Auth0 pour modifier les scopes d’un et/ou ajouter des revendications personnalisées aux jetons d’accès et aux . Pour en savoir plus sur les Actions, consultez Comprendre le fonctionnement des Actions Auth0. Pour ce faire, ajoutez l’Action Post-Login suivante, qui s’exécutera une fois l’utilisateur authentifié :
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 le scope du jeton d'accès
  api.accessToken.addScope('foo');
  api.accessToken.addScope('bar');
};
Auth0 renvoie les informations de profil sous forme de revendications structurées, comme le définit la spécification OpenID Connect (OIDC). Cela signifie que les revendications personnalisées ajoutées aux ID tokens ou aux jetons d’accès doivent respecter les directives et restrictions afin d’éviter d’éventuelles collisions.

En savoir plus