Ce tutoriel vous aide à appeler votre propre API à partir d’une application native, mobile ou à page unique en utilisant le flux de code d’autorisation avec PKCE. Pour savoir comment fonctionne le flux et pourquoi vous devriez l’utiliser, consultez Flux de code d’autorisation avec Proof Key for Code Exchange (PKCE). Pour apprendre à ajouter une connexion à votre application native, mobile ou à page unique, consultez Ajout d’une connexion avec le flux de code d’autorisation avec une Proof Key for Code Exchange (PCKE).
- Trousse SDK mobile d’Auth0 et trousse SDK pour application Web monopage d’Auth0 : la manière la plus simple d’implémenter le flux, qui fera le gros du travail à votre place. Notre Guide de démarrages rapides mobiles et Guide de démarrages rapides d’applications Web monopages vous guideront tout au long du processus.
- Authentication API : Si vous préférez créer votre propre solution, continuez à lire pour savoir comment appeler notre API directement.
Prérequis
Avant de commencer ce tutoriel :-
Enregistrez l’application avec Auth0.
- Sélectionnez un Type d’application entre Natif ou à page unique, en fonction de votre type de demande.
- Ajoutez une URL de rappel autorisée de
{yourCallbackUrl}. Le format de l’URL de rappel varie en fonction du type d’application et de la plateforme. Pour plus de détails sur le format de votre type d’application et de votre plateforme, consultez notre Guide de démarrages rapides natifs/mobiles et Guide de démarrages rapides pour application Web à page unique . - 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.
-
Enregistrez votre application avec Auth0
- 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.
Étapes
- Créer un vérificateur de code :
Générez un
code_verifierqui sera envoyé à Auth0 pour demander des jetons. - Créer un défi-réponse avec code :
Générez un
code_challengeà partir ducode_verifierqui sera envoyé à Auth0 pour demander unauthorization_code. - Autoriser l’utilisateur :
Demandez l’autorisation de l’utilisateur et redirigez-le vers votre application à l’aide d’un
authorization_code. - Demande de jeton :
Échangez votre
authorization_codeet votrecode_verifierpour des jetons. - Appel d’API : Utilisez le jeton d’accès récupéré pour appeler votre API.
- Jetons d’actualisation : Utilisez un jeton d’actualisation pour demander de nouveaux jetons lorsque les jetons existants expirent.
Créer un vérificateur de code
Créez uncode_verifier, qui est une clé cryptographiquement aléatoire encodée en Base64 et qui sera finalement envoyée à Auth0 pour demander des jetons.
Exemple de JavaScript
Exemple Java
Exemple Android
Échantillon Swift 5
Exemple en Objective-C
Créer un défi de code
Générez uncode_challenge à partir du code_verifier qui sera envoyé à Auth0 pour demander un autorisation_code.
Exemple de JavaScript
Exemple Java
Échantillon Swift 5
Exemple en Objective-C
Autoriser l’utilisateur
Une fois que vous avez créé lecode_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.
Exemple d’un 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 d’
- pouvez inclure des permissions supplémentaires prises en charge par l’API cible
Par exemple, votre extrait HTML pour votre URL d’autorisation lorsque vous appelez un API pourrait ressembler à ceci :
Réponse
Si tout se passe bien, vous recevrez une réponseHTTPº302. Le code d’autorisation est compris à la fin de cette URL :
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 en l’envoyant avec le code_verifier.
Exemple de POSR à une URL de jeton
Paramètres
Réponse
Si tout se passe bien, vous recevrez une réponse HTTP 200 avec une charge utile contenant les valeursaccess_token, refresh_token, ID_token et token_type :
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.
Appel d’API
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.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_accesslorsque vous avez lancé la demande d’authentification via le point de terminaison d’autorisation.
POST au point de terminaison /oauth/token dans l’Authentication API, à l’aide de grant_type=refresh_token.
Exemple de POSR à une URL de jeton
Paramètres
Réponse
Si tout se passe bien, vous recevrez une réponseHTTP 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 :