Ajouter une fonctionnalité de connexion à l’aide du flux de code d’autorisation avec PKCE
Découvrez comment ajouter une fonctionnalité de connexion à votre application native, mobile ou monopage à l’aide du flux de code d’autorisation avec PKCE.
Vous pouvez ajouter la connexion à votre application native, mobile ou monopage à l’aide du flux de code d’autorisation avec PKCE. Pour savoir comment ce flux fonctionne et pourquoi vous devriez l’utiliser, consultez Flux de code d’autorisation avec Proof Key for Code Exchange (PKCE). Pour savoir comment appeler votre API à partir d’une application native, mobile ou monopage, consultez Appeler votre API à l’aide du flux de code d’autorisation avec PKCE.Pour implémenter le flux de code d’autorisation avec Proof Key for Code Exchange (PKCE), vous pouvez utiliser les ressources suivantes :
Authentication API : Si vous préférez créer votre propre solution, poursuivez votre lecture pour apprendre à appeler directement notre API.
Après une connexion réussie, votre application aura accès au et au de l’utilisateur. Le jeton d’identité contiendra les renseignements de base du profil utilisateur, et le jeton d’accès peut servir à appeler le point de terminaison /userinfo d’Auth0 ou vos propres API protégées. Pour en savoir plus sur les ID tokens, consultez ID Tokens. Pour en savoir plus sur les jetons d’accès, consultez Access Tokens.
Sélectionnez un Type d’application de Native ou Application monopage, selon le type de votre application.
Ajoutez YOUR_CALLBACK_URL comme URL de rappel autorisée. Le format de votre URL de rappel varie selon le type et la plateforme de votre application. Pour plus de détails sur le format correspondant à votre type d’application et à votre plateforme, consultez nos guides de démarrage rapide Native/Mobile et guides de démarrage rapide Application monopage.
Assurez-vous que les Types d’octroi de votre application incluent Code d’autorisation. Pour en savoir plus, consultez Mettre à jour les types d’octroi.
Créez un code_verifier, c’est-à-dire une clé aléatoire cryptographiquement sécurisée, encodée en Base64, qui sera ensuite envoyée à Auth0 pour demander des jetons.Pour en savoir plus sur l’algorithme utilisé pour créer le code_verifier, consultez la section 4.1 Client Creates a Code Verifier de la spécification Proof Key for Code Exchange.
// Dépendance : Apache Commons Codec// https://commons.apache.org/proper/commons-codec/// Importer la classe Base64.// import org.apache.commons.codec.binary.Base64;SecureRandom sr = new SecureRandom();byte[] code = new byte[32];sr.nextBytes(code);String verifier = Base64.getUrlEncoder().withoutPadding().encodeToString(code);
Générez un code_challenge à partir du code_verifier, qui sera envoyé à Auth0 pour demander un authorization_code.Pour en savoir plus sur la façon dont le code_challenge est généré à partir du code_verifier, consultez la section 4.2 Le client crée le code challenge de la spécification OAuth Proof Key for Code Exchange.
Demandez l’autorisation de l’utilisateur et redirigez-le vers votre application avec un authorization_code.Une fois le code_verifier et le code_challenge créés, vous devez obtenir l’autorisation de l’utilisateur. Techniquement, c’est le début du , et cette étape peut comprendre un ou plusieurs des processus suivants :
Authentifier l’utilisateur;
Rediriger l’utilisateur vers un pour prendre en charge l’authentification;
Obtenir le consentement de l’utilisateur pour le niveau d’autorisation demandé, sauf s’il a déjà été accordé.
Pour autoriser l’utilisateur, votre application doit le rediriger vers l’URL d’autorisation, en incluant le code_challenge généré à l’étape précédente ainsi que la méthode utilisée pour le générer.
Indique le type d’identifiant qu’Auth0 renverra (code ou token). Pour ce flux, la valeur doit être code.
code_challenge
Défi généré à partir du code_verifier.
code_challenge_method
Méthode utilisée pour générer le défi (par ex. S256). La spécification PKCE définit deux méthodes, S256 et plain ; la première est utilisée dans cet exemple et c’est la seule qu’Auth0 prend en charge, puisque la seconde est déconseillée.
L’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 indiquer cette URL comme URL de rappel valide dans vos paramètres de l’application.
Avertissement : Conformément à la spécification OAuth 2.0, Auth0 supprime tout ce qui suit le hash et ignore les fragments.
scope
Précise les scopes pour lesquels vous souhaitez demander une autorisation, ce qui détermine quelles claims (ou quels attributs utilisateur) vous voulez voir renvoyés. Ils doivent être séparés par un espace. Pour obtenir un ID Token dans la réponse, vous devez préciser au minimum le scope openid. Si vous souhaitez renvoyer le profil complet de l’utilisateur, vous pouvez demander openid profile. Vous pouvez demander n’importe lequel des scopes OpenID Connect (OIDC) standard concernant les utilisateurs, comme email, ou des custom claims conformes à un format avec espace de noms. 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).
state
(recommandé) Chaîne alphanumérique arbitraire et 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 intersites (CSRF), consultez Mitigate CSRF Attacks With State Parameters.
connection
(facultatif) Force l’utilisateur à se connecter avec une connexion précise. Par exemple, vous pouvez transmettre la valeur github pour envoyer directement l’utilisateur vers GitHub afin qu’il se connecte avec son compte GitHub. Lorsqu’elle n’est pas précisée, l’utilisateur voit l’écran Auth0 Lock avec toutes les connexions configurées. Vous pouvez voir la liste de vos connexions configurées dans l’onglet Connections de votre application.
organization
(facultatif) ID de l’organisation à utiliser lors de l’authentification d’un utilisateur. Lorsqu’il n’est pas fourni, si votre application est configurée pour Display Organization Prompt, l’utilisateur pourra saisir le nom de l’organisation au moment de l’authentification.
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, votre extrait HTML pour votre URL d’autorisation lors de l’ajout de la connexion à votre application pourrait ressembler à ceci :
Échangez votre authorization_code et votre code_verifier contre des jetons.Maintenant que vous avez un code d’autorisation, vous devez l’échanger contre des jetons. À l’aide du code d’autorisation extrait (code) à l’étape précédente, vous devrez envoyer une requête POST à l’URL du jeton avec le code_verifier.
L’URL de rappel valide configurée dans les paramètres de votre application. Elle doit correspondre exactement au redirect_uri transmis à l’URL d’autorisation à l’étape précédente de ce tutoriel. Notez qu’elle doit être encodée au format URL.
Si tout se passe bien, vous recevrez une réponse HTTP 200 avec un payload qui contient les valeurs access_token, refresh_token, id_token et token_type :
Les ID tokens contiennent des informations sur l’utilisateur qui doivent être décodées et extraites.Les jetons d’accès servent à appeler l’endpoint /userinfo de l’Auth0 Authentication API ou une autre API. Si vous appelez votre propre API, la première chose qu’elle devra faire sera de vérifier le jeton d’accès.Les jetons d’actualisation servent à obtenir un nouveau jeton d’accès ou un 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 l’Auth0 Dashboard.
Les jetons d’actualisation doivent être stockés de façon sécurisée, car ils permettent à un utilisateur de rester authentifié pratiquement indéfiniment.
Cet exemple montre la requête la plus élémentaire que vous pouvez effectuer lors de l’autorisation de l’utilisateur à l’étape 1. Il affiche l’écran de connexion d’Auth0 et permet à l’utilisateur de se connecter à l’aide de n’importe laquelle de vos connexions configurées :Maintenant, lorsque vous demanderez des jetons, votre ID Token contiendra les claims de base. Lorsque vous décoderez l’ID Token, il ressemblera à ceci :
Demander le nom et la photo de profil de l’utilisateur
En plus de l’authentification standard de l’utilisateur, cet exemple montre comment demander des renseignements supplémentaires, comme son nom et sa photo.Pour demander le nom et la photo de l’utilisateur, vous devez ajouter les scopes appropriés lorsque vous autorisez l’utilisateur :Désormais, lorsque vous demanderez des jetons, votre jeton d’identité contiendra les claims name et picture demandées. Lorsque vous décoderez le jeton d’identité, il ressemblera à ceci :
Demander à l’utilisateur de se connecter avec GitHub
En plus de l’authentification habituelle des utilisateurs, cet exemple montre comment rediriger les utilisateurs directement vers un fournisseur d’identité social, comme GitHub. Pour que cet exemple fonctionne, vous devez aller à Auth0 Dashboard > Authentification > Social et configurer la connexion appropriée. Relevez le nom de la connexion dans l’onglet Settings.Pour envoyer les utilisateurs directement à l’écran de connexion de GitHub, vous devez transmettre le paramètre connection et définir sa valeur sur le nom de la connexion (dans ce cas, github) au moment d’autoriser l’utilisateur :Désormais, lorsque vous demanderez des jetons, votre jeton d’identité contiendra une revendication sub avec l’identifiant unique de l’utilisateur renvoyé par GitHub. Lorsque vous décoderez le jeton d’identité, il ressemblera à ceci :