Skip to main content

Aperçu

Concepts clés
  • Découvrez le type d’octroi OAuth 2.0, le flux de code d’autorisation avec clé de preuve pour l’échange de code (PKCE).
  • Utilisez ce type d’octroi pour les applications qui ne peuvent pas stocker de secret client, comme les applications natives ou monopages.
  • Découvrez différentes méthodes de mise en œuvre avec les Auth0 SDKs.
Lorsque des (p. ex., les applications natives et monopages) demandent des , cela soulève des enjeux de sécurité supplémentaires que le flux de code d’autorisation, à lui seul, ne permet pas d’atténuer. En effet : Applications natives
  • Ne peuvent pas stocker de façon sécuritaire un . La décompilation de l’application révélera le , qui est associé à l’application et identique pour tous les utilisateurs et appareils.
  • Sont vulnérables aux attaques d’interception et d’injection du code d’autorisation. Sans secret client, un attaquant qui intercepte le code d’autorisation peut l’échanger contre des jetons.
  • Peuvent utiliser un schéma d’URI personnalisé pour capter les redirections (p. ex., MyApp://), ce qui pourrait permettre à des applications malveillantes de recevoir un de votre . En raison de ce risque, Auth0 déconseille fortement l’utilisation de schémas d’URI personnalisés. Pour en savoir plus, consultez Measures Against Application Impersonation.
Applications monopages
  • Ne peuvent pas stocker de façon sécuritaire un secret client, parce que l’ensemble de leur code source est accessible dans le navigateur.
Dans ces situations, propose une version du flux de code d’autorisation qui utilise une clé de preuve pour l’échange de code (PKCE) (définie dans OAuth 2.0 RFC 7636). Le flux de code d’autorisation amélioré par PKCE introduit un secret créé par l’application appelante et que le peut vérifier; ce secret s’appelle le Code Verifier. De plus, l’application appelante crée une valeur dérivée du Code Verifier appelée le Code Challenge et envoie cette valeur en HTTPS pour obtenir un code d’autorisation. Ainsi, un attaquant malveillant ne peut intercepter que le code d’autorisation et ne peut pas l’échanger contre un jeton sans le Code Verifier.

​
Fonctionnement

Comme le flux de code d’autorisation avec PKCE s’appuie sur le flux de code d’autorisation standard, les étapes sont très similaires.
Flows - Code d’autorisation avec PKCE - Diagramme de séquence d’autorisation
  1. L’utilisateur clique sur Login dans l’application.
  2. Le SDK d’Auth0 crée un code_verifier cryptographiquement aléatoire, puis génère à partir de celui-ci un code_challenge.
  3. Le SDK d’Auth0 redirige l’utilisateur vers le serveur d’autorisation Auth0 (point de terminaison /authorize) avec le code_challenge.
  4. Votre serveur d’autorisation Auth0 redirige l’utilisateur vers le prompt de connexion et d’autorisation.
  5. L’utilisateur s’authentifie à l’aide de l’une des options de connexion configurées et peut voir une page de consentement présentant les permissions qu’Auth0 accordera à l’application.
  6. Votre serveur d’autorisation Auth0 stocke le code_challenge et redirige l’utilisateur vers l’application avec un code d’autorisation, valable pour une seule utilisation.
  7. Le SDK d’Auth0 envoie ce code et le code_verifier (créé à l’étape 2) au serveur d’autorisation Auth0 (point de terminaison /oauth/token).
  8. Votre serveur d’autorisation Auth0 vérifie le code_challenge et le code_verifier.
  9. Votre serveur d’autorisation Auth0 renvoie un jeton d’identité et un jeton d’accès (et, au besoin, un jeton d’actualisation).
  10. Votre application peut utiliser le jeton d’accès pour effectuer une requête à une API afin d’accéder à des renseignements sur l’utilisateur.
  11. L’API renvoie les données demandées.
Si la rotation des jetons d’actualisation est activée, un nouveau jeton d’actualisation est généré à chaque requête et émis avec le jeton d’accès. Lorsqu’un jeton d’actualisation est échangé, le jeton d’actualisation précédent est invalidé, mais l’information sur cette relation est conservée par le serveur d’autorisation.

​
Comment l’implémenter

La façon la plus simple d’implémenter le flux de code d’autorisation avec PKCE est de suivre nos Quickstarts pour applications natives ou de suivre nos Quickstarts pour SPA. Selon votre type d’application, vous pouvez aussi utiliser nos SDK mobiles ou pour application monopage : Mobile Application monopage
Les progrès récents des contrôles de confidentialité dans les navigateurs nuisent à l’expérience utilisateur en bloquant l’accès aux cookies tiers; par conséquent, les flux basés sur le navigateur doivent utiliser la rotation des jetons d’actualisation, qui offre une méthode sécurisée pour utiliser des jetons d’actualisation dans les SPA tout en assurant aux utilisateurs finaux un accès fluide aux ressources, sans les interruptions de l’expérience utilisateur causées par des technologies de confidentialité des navigateurs comme ITP.
Vous pouvez suivre nos tutoriels pour utiliser nos points de terminaison d’API afin d’ajouter la connexion à l’aide du flux de code d’autorisation avec PKCE ou d’appeler votre API à l’aide du flux de code d’autorisation avec PKCE.

​
En savoir plus