Skip to main content
Le cadre d’autorisation OAuth 2.0 prend en charge plusieurs flux (ou grants) différents. Les permettent d’obtenir un . Le choix du flux adapté à votre cas d’utilisation dépend surtout de votre type d’application, mais d’autres paramètres entrent aussi en ligne de compte, comme le niveau de confiance accordé au client ou l’expérience que vous souhaitez offrir à vos utilisateurs.

​
Terminologie OAuth 2.0

  • : Entité capable d’accorder l’accès à une ressource protégée. Il s’agit généralement de l’utilisateur final.
  • Client: Application qui demande l’accès à une ressource protégée au nom du propriétaire de la ressource.
  • : Serveur qui héberge les ressources protégées. Il s’agit de l’API à laquelle vous voulez accéder.
  • : Serveur qui authentifie le propriétaire de la ressource et émet des jetons d’accès après avoir obtenu l’autorisation appropriée. Dans ce cas-ci, il s’agit d’Auth0.
  • Agent utilisateur: Agent utilisé par le propriétaire de la ressource pour interagir avec le client (par exemple, un navigateur ou une application native).

​
Le Client est-il le propriétaire de la ressource ?

Le premier point de décision consiste à déterminer si l’entité qui doit accéder aux ressources est une machine. Dans le cas d’une autorisation machine-to-machine, le Client est aussi le propriétaire de la ressource, donc aucune autorisation de l’utilisateur final n’est nécessaire. Par exemple, un cron job peut utiliser une API pour importer des renseignements dans une base de données. Dans cet exemple, le cron job est le Client et le propriétaire de la ressource, puisqu’il détient le et le et les utilise pour obtenir un jeton d’accès auprès du serveur d’autorisation. Si ce cas correspond à vos besoins, consultez Client Credentials Flow pour comprendre le fonctionnement de ce flux et savoir comment le mettre en œuvre.

​
Le Client est-il une application web qui s’exécute sur le serveur ?

Si le Client est une application web traditionnelle qui s’exécute sur un serveur, le Flux de code d’autorisation est celui que vous devriez utiliser. Grâce à lui, le Client peut récupérer un jeton d’accès et, au besoin, un . Il est considéré comme le choix le plus sûr, puisque le jeton d’accès est transmis directement au serveur web qui héberge le Client, sans passer par le navigateur de l’utilisateur ni risquer d’être exposé. Si cette situation correspond à vos besoins, consultez Flux de code d’autorisation pour comprendre son fonctionnement et voir comment l’implémenter.

​
Peut-on faire absolument confiance au client avec les identifiants de l’utilisateur?

Ce point de décision peut mener à l’octroi par mot de passe du propriétaire de la ressource. Dans ce flux, on demande à l’utilisateur final de saisir ses identifiants (identifiant/mot de passe), généralement au moyen d’un formulaire interactif. Ces renseignements sont envoyés au backend, puis transmis à Auth0. Il est donc impératif que le client soit absolument digne de confiance pour traiter ces renseignements. Cet octroi ne devrait être utilisé que lorsque les flux avec redirection (comme le flux de code d’autorisation) ne sont pas possibles. Si c’est votre cas, consultez le flux par mot de passe du propriétaire de la ressource pour comprendre son fonctionnement et la façon de l’implémenter.

​
Le client est-il une application monopage ?

Si le client est une application monopage (SPA), c’est-à-dire une application qui s’exécute dans un navigateur à l’aide d’un langage de script comme Javascript, deux options de grant s’offrent à vous : le flux de code d’autorisation avec PKCE et le flux implicite avec Form Post. Dans la plupart des cas, nous recommandons d’utiliser le flux de code d’autorisation avec PKCE, car le jeton d’accès n’est pas exposé côté client et ce flux peut renvoyer des jetons d’actualisation. Pour en savoir plus sur le fonctionnement de ce flux et sur la façon de l’implémenter, consultez Flux de code d’autorisation avec clé de preuve pour l’échange de code (PKCE). Le Auth0 Single-Page App SDK fournit une API de haut niveau pour implémenter le flux de code d’autorisation avec PKCE dans les SPA. Si votre SPA n’a pas besoin d’un jeton d’accès, vous pouvez utiliser le flux implicite avec Form Post. Pour en savoir plus sur le fonctionnement de ce flux et sur la façon de l’implémenter, consultez Flux implicite avec Form Post.

​
Le client est-il une application native/mobile ?

Si l’Application est une application native, utilisez le flux de code d’autorisation avec clé de preuve pour l’échange de code (PKCE). Pour en savoir plus sur le fonctionnement de ce flux et sur sa mise en œuvre, consultez flux de code d’autorisation avec clé de preuve pour l’échange de code (PKCE).

​
J’ai une application qui doit communiquer avec différents serveurs de ressources

Si une même application a besoin de jetons d’accès pour différents serveurs de ressources, plusieurs requêtes vers /authorize (c’est-à-dire plusieurs exécutions du même ou d’un autre) sont nécessaires. Chaque autorisation utilisera une valeur différente pour audience, ce qui se traduira par un jeton d’accès différent à la fin du flux. Pour en savoir plus, consultez la spécification OAuth 2.0: Audience Information Specification.

​
Puis-je tester les endpoints avant d’implémenter mon application?

Bien sûr! Vous pouvez utiliser notre extension Authentication API Debugger. Vous trouverez des instructions détaillées pour chaque endpoint /grant dans notre Authentication API Reference.
  • Pour l’endpoint Authorize, consultez Authorize Application et lisez le paragraphe « Test this endpoint » pour le grant que vous souhaitez tester.
  • Pour le , consultez obtenir un jeton et lisez la section « Test this endpoint » pour le grant que vous souhaitez tester.

​
L’Application cliente doit-elle demander aux utilisateurs de s’authentifier sans passer par un navigateur?

Client-Initiated Backchannel Authentication est actuellement en accès anticipé. Pour activer CIBA, communiquez avec votre chargé de compte technique.
Client-Initiated Backchannel Authentication (CIBA) est une norme de l’ Foundation qui permet de mettre en œuvre un flux d’authentification différent de OpenID Connect. CIBA diffère du flux OpenID Connect standard en ce que :
  • L’application cliente lance le processus d’authentification au nom de l’utilisateur final.
  • Il n’est pas nécessaire d’utiliser un navigateur pour interagir avec l’utilisateur.
  • Il existe une communication directe entre l’application cliente et le fournisseur OpenID.
CIBA est utile lorsque l’utilisateur ne peut pas se fier à l’application cliente, que l’application cliente n’a pas de navigateur ou que l’utilisateur n’est pas devant l’application qui exige l’authentification. Voici quelques exemples où les flux CIBA peuvent être utilisés :
  • Arrivée de l’utilisateur à une borne de vente en magasin : dans un scénario de ramassage en magasin, l’utilisateur peut s’authentifier à une borne publique et confirmer sa présence.
  • Authentification dans un centre d’appels ou au comptoir d’un préposé : un agent de centre d’appels peut lancer un flux d’authentification pour authentifier un appelant, généralement au moyen d’une application mobile personnalisée sur un téléphone intelligent.
  • Authentification sur un appareil sans dispositif d’entrée : par exemple, un haut-parleur intelligent (ou un autre appareil connecté) peut utiliser un service backend pour joindre l’utilisateur afin de l’authentifier, généralement au moyen d’une application mobile personnalisée sur un téléphone intelligent.
CIBA définit deux appareils :
  • appareil de consommation : l’appareil qui permet à l’utilisateur de consommer un service.
  • appareil d’authentification : l’appareil sur lequel l’utilisateur s’authentifiera et accordera son consentement.
Pour en savoir plus, consultez Client-Initiated Backchannel Authentication Flow.