Appeler votre API avec le flux de code d’autorisation avec une clé de preuve pour l’échange de code (PKCE)
Découvrez comment appeler votre API à partir de votre application native, mobile ou à page unique en utilisant le flux Codes d’autorisation à l’aide d’une Proof Key for Code Exchange (PKCE).
Assurez-vous que les Grant Types (Types d’autorisation) de l’application comprennent 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 incluent 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 souhaitez 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.
Créez un code_verifier, qui est une clé cryptographiquement aléatoire encodée en Base64 et qui sera finalement envoyée à Auth0 pour demander des jetons.
// See https://developer.android.com/reference/android/util/Base64// Import the Base64 class// import android.util.Base64;SecureRandom sr = new SecureRandom();byte[] code = new byte[32];sr.nextBytes(code);String verifier = Base64.encodeToString(code, Base64.URL_SAFE | Base64.NO_WRAP | Base64.NO_PADDING);
Une fois que vous avez créé le code_verifier et le code_challenge, vous devez obtenir l’autorisation de l’utilisateur. Il s’agit techniquement du début du flux d’autorisation, et cette étape peut inclure un ou plusieurs des processus suivants :* Authentification de l’utilisateur;
* Rediriger l’utilisateur vers un fournisseur d’identité pour gérer l’authentification;
* Vérification des sessions d’authentification unique (SSO) actives;
* Obtention du consentement de l’utilisateur pour le niveau d’autorisation demandé, sauf si le consentement a été préalablement donné.Pour autoriser l’utilisateur, votre application doit envoyer l’utilisateur vers l’URL d’autorisation, y compris le code_challenge que vous avez généré à l’étape précédente et la méthode que vous avez utilisée pour générer le code_challenge.
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 genre d’identifiant que Auth0 retournera (code ou token). Pour ce flux, la valeur doit être code.
code_challenge
Défi généré par le code_verifier.
code_challenge_method
Méthode utilisée pour générer le défi (p. ex., S256). La spécification PKCE définit deux méthodes, S256 et plain; la première est utilisée dans cet exemple et est seulement prise en charge par Auth0 puisque cette dernière est déconseillée.
client_id
L’ID client de votre application. Vous pouvez trouver cette valeur dans vos Paramètres d’application.
redirect_uri
L’URL vers laquelle Auth0 redirigera le navigateur après autorisation accordée par l’utilisateur. Le code d’autorisation sera disponible dans le paramètre URL du code. Vous devez spécifier cette URL comme URL de rappel valide dans vos [Paramètres d’application].(https://manage.auth0.com/#/Applications/{yourClientId}/settings).
Avertissement: Selon la spécification OAuth 2.0, Auth0 supprime tout après le hachage et n’honore aucun fragment.
scope
Les permissions pour lesquelles vous voulez demander l’autorisation. Elles doivent être séparées par un espace. Vous pouvez demander l’une des permissions standard OpenID Connect (OIDC) au sujet des utilisateurs, comme le profile et le email, demandes personnalisées conformes à un format avec espace de noms, ou toute permission prise en charge par l’API cible (p. ex., read:contacts). Inclure offline_access pour obtenir un Jeton d’actualisation (assurez-vous que le champ Allow Offline Access est activé dans les Paramètres d’application).
audience
L’identifiant unique de l’API à laquelle votre application mobile souhaite accéder. Utilisez la valeur Identifier dans l’onglet Paramètres 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 est ajoutée à la demande initiale que Auth0 inclut lors de la redirection vers votre application. Pour voir comment utiliser cette valeur pour empêcher les attaques de falsification des requêtes entre sites (CSRF), voir Atténuer les attaques CSRF avec les paramètres d’état.
organization
(facultatif) ID de l’organisation à utiliser pour authentifier un utilisateur. Lorsqu’il n’est pas fourni, si 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 de billet de l’invitation d’organisation. Au moment d’inviter un membre à une organisation, votre application doit traiter l’acceptation de l’invitation en transmettant les paires clé-valeur invitation et organization lorsque l’utilisateur accepte l’invitation.
Par exemple, votre extrait HTML pour votre URL d’autorisation lorsque vous appelez un API pourrait ressembler à ceci :
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 en l’envoyant avec le code_verifier.
L’URL de rappel valide défini dans les paramètres de votre application. Cela doit correspondre exactement au redirect_uri transmis à 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 et token_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 native/communication entre machines (M2M), l’application doit transmettre le jeton d’accès récupéré en tant que jeton du porteur dans l’en-tête Authorization (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 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.
