Découvrez comment déterminer le flux OAuth 2.0 qui convient à votre cas d’utilisation.
Le cadre d’autorisation OAuth 2.0 prend en charge plusieurs flux (ou types d’octroi). Les sont des moyens 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.
: Entité qui peut 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. C’est 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 nécessaire. 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 à trancher consiste à déterminer si l’entité qui doit accéder aux ressources est une machine. Dans le cas d’une autorisation entre machines, le client est aussi le propriétaire de la ressource; aucune autorisation de l’utilisateur final n’est donc nécessaire. Par exemple, une tâche cron peut utiliser une API pour importer des données dans une base de données. Dans cet exemple, la tâche cron est le client et le propriétaire de la ressource puisqu’elle détient le et le et les utilise pour obtenir un jeton d’accès auprès du serveur d’autorisation.Si cette situation correspond à vos besoins, consultez Client Credentials Flow pour comprendre son fonctionnement et voir comment l’implémenter.
Le client est-il une application Web exécutée sur un serveur ?
Si le client est une application Web classique exécutée sur un serveur, le flux de code d’autorisation est celui à privilégier. Grâce à ce flux, le client peut récupérer un jeton d’accès et, au besoin, un . Il est considéré comme l’option la plus sûre, puisque le jeton d’accès est transmis directement au serveur Web qui héberge le client, sans passer par le navigateur Web de l’utilisateur, ce qui réduit les risques d’exposition.Si cette situation correspond à vos besoins, consultez flux de code d’autorisation pour comprendre le fonctionnement de ce flux et voir comment l’implémenter.
Le client est-il absolument digne de confiance en ce qui concerne les identifiants de l’utilisateur?
Ce point de décision peut mener à l’octroi « Resource Owner Password Credentials Grant ». Dans ce flux, on demande à l’utilisateur final de saisir ses identifiants (identifiant/mot de passe), généralement à l’aide d’un formulaire interactif. Ces renseignements sont envoyés au serveur principal, puis à Auth0. Il est donc impératif que le client soit absolument digne de confiance pour recevoir ces renseignements.Cet octroi ne devrait être utilisé que lorsque les flux avec redirection (comme le flux de code d’autorisation) sont impossibles. Si c’est votre cas, consultez Resource Owner Password Flow pour savoir comment ce flux fonctionne et comment l’implémenter.
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 d’octroi sont possibles : le flux de code d’autorisation avec Proof Key for Code Exchange (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, puisque 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 Authorization Code Flow with Proof Key for Code Exchange (PKCE). Le SDK Auth0 Single-Page App 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 Implicit Flow with Form Post.
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, il faut effectuer plusieurs appels à /authorize (c’est-à-dire exécuter plusieurs fois le même ou différents flux d’autorisation). Chaque autorisation utilisera une valeur différente pour audience, ce qui produira un jeton d’accès différent à la fin du flux. Pour en savoir plus, consultez la spécification OAuth 2.0: Audience Information.
Pour le point de terminaison Authorize, allez à Authorize Application et lisez le paragraphe « Test this endpoint » pour le type d’autorisation que vous voulez tester.
Pour le , allez à Get Token et lisez la section « Test this endpoint » pour le type d’autorisation que vous voulez tester.
L’application cliente doit-elle demander aux utilisateurs de s’authentifier sans interaction avec le navigateur ?
L’authentification backchannel initiée par le client est actuellement en accès anticipé. Pour activer CIBA, communiquez avec votre gestionnaire de compte technique.
L’authentification backchannel initiée par le client (CIBA) est une norme de l’ Foundation qui permet de mettre en œuvre un flux d’authentification alternatif à OpenID Connect. CIBA se distingue du flux OpenID Connect habituel de la façon suivante :
l’application cliente lance le processus d’authentification au nom de l’utilisateur final.
aucun navigateur n’est nécessaire pour l’interaction avec l’utilisateur.
la communication se fait directement entre l’application cliente et le fournisseur OpenID.
CIBA est utile lorsque l’utilisateur ne fait pas confiance à l’application cliente, que l’application cliente n’a pas de navigateur ou que l’utilisateur ne se trouve pas devant l’application qui exige l’authentification. Voici quelques exemples d’utilisation des flux CIBA :
Arrivée de l’utilisateur à une borne de vente au détail : dans les scénarios de ramassage en magasin, un utilisateur peut s’authentifier à une borne publique et confirmer sa présence.
Authentification dans un centre d’appels ou au comptoir d’un agent : un agent de centre d’appels peut lancer un flux d’authentification pour authentifier un appelant, généralement à l’aide 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 d’arrière-plan pour communiquer avec l’utilisateur aux fins d’authentification, généralement à l’aide d’une application mobile personnalisée sur un téléphone intelligent.
CIBA définit deux appareils :
Appareil d’accès au service : l’appareil qui permet à l’utilisateur d’utiliser un service.
Appareil d’authentification : l’appareil sur lequel l’utilisateur s’authentifiera et accordera son consentement.
Authentification
Gérer les utilisateurs
Personnaliser
Auth0 AI
Plateforme