- Trousses SDK Auth0 Mobile et Trousse SDK Auth0 pour applications à page unique : Manière la plus simple d’implémenter le flux, qui fera le gros du travail à votre place. Nos Démarrages rapides Mobile et Démarrages rapides pour applications à page unique vous guideront tout au long du processus.
- Authentication API : Si vous préférez créer votre propre solution, poursuivez la lecture pour savoir comment appeler notre API directement.
/userinfo ou vos propres API protégées. Pour en savoir plus sur les jetons d’ID, consultez Jetons d’ID. Pour en savoir plus sur les jetons d’accès, consultez Jetons d’accès.
Prérequis
Enregistrez votre application auprès d’Auth0. Pour en apprendre davantage, consultez Enregistrement d’applications natives ou Enregistrement d’applications Web à page unique.- Sélectionnez un type d’applicationnative ou à page unique, selon le type de votre application.
- Ajoutez une URL de rappel autorisée de
VOTRE_URL_RAPPEL. 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 correspondant à votre type d’application et à votre plateforme, consultez Démarrages rapides Native/Mobile et Démarrages rapides Application à page unique. - Assurez-vous que les Grant Types (Types d’autorisation) de votre application comprennent le code d’autorisation. Pour en savoir plus, lisez Mettre à jour les types d’autorisation.
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.
Pour en savoir plus sur l’algorithme de création du code_verifier, consultez la section 4.1 Client crée un vérificateur de code des spécifications de Proof Key for Code Exchange (PKCE).
Exemple JavaScript
Exemple Java
Exemple Android
Échantillon Swift 5
Exemple 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.
Pour en savoir plus sur la façon dont le code_challenge est dérivé du code_verifier, consultez la section 4.2 Client crée le défi du code des spécifications de OAuth Proof Key for Code Exchange (PKCE).
Exemple JavaScript
Exemple Java
Échantillon Swift 5
Exemple Objective-C
Autoriser l’utilisateur
Demandez l’autorisation de l’utilisateur et redirigez-le vers votre application à l’aide d’unauthorization_code.
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.
Exemple d’URL d’autorisation
Paramètres
Par exemple, votre snippet HTML pour l’URL d’autorisation lors de l’ajout d’une connexion à votre application pourrait ressembler à ceci :
Réponse
Si tout se passe bien, vous recevrez une réponseHTTP 302. Le code d’autorisation est ajouté à la fin de l’URL :
Jetons de requête
Échangez votreauthorization_code et code_verifier pour 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 d’URL « POST to token »
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.
Cas d’utilisation
Demande d’authentification de base
Cet exemple montre la requête la plus basique que vous pouvez faire lorsque vous autorisez l’utilisateur à l’étape 1. L’écran de connexion Auth0 permet à l’utilisateur de se connecter avec l’une des connexions configurées. Désormais, lorsque vous demanderez des jetons, votre jeton d’ID contiendra les autorisations les plus élémentaires. Lorsque vous décodez le jeton d’ID, il ressemble à ce qui suit :Demander le nom et la photo de profil de l’utilisateur
Outre l’authentification habituelle de l’utilisateur, cet exemple montre comment demander des informations supplémentaires sur l’utilisateur, telles que son nom et sa photo. Pour demander le nom et la photo de l’utilisateur, vous devez ajouter les permissions appropriées lors de l’autorisation de l’utilisateur : Désormais, lorsque vous demanderez des jetons, votre jeton d’ID contiendra le nom et la photo demandés. Lorsque vous décodez le jeton d’ID, il ressemble à ce qui suit :Demande de connexion d’un utilisateur avec GitHub
En plus de l’authentification habituelle des utilisateurs, cet exemple montre comment envoyer les utilisateurs directement à un fournisseur d’identité sociale, tel que GitHub. Pour que cet exemple fonctionne, vous devez aller dans Auth0 Dashboard > Authentification > Social et configurer la connexion appropriée. Obtenez le nom de la connexion dans l’onglet Paramètres. Pour envoyer les utilisateurs directement à l’écran de connexion de GitHub, vous devez passer le paramètreconnection et définir sa valeur au nom de la connexion (dans ce cas, github) lors de l’autorisation de l’utilisateur :
Désormais, lorsque vous demandez des jetons, votre jeton d’ID contiendra une demande sub avec l’ID unique de l’utilisateur renvoyé par GitHub. Lorsque vous décodez le jeton d’ID, il ressemble à ce qui suit :