Quel flux OAuth 2.0 dois-je utiliser?

Le cadre d’applications Authorization OAuth 2.0 prend en charge différents flux (ou autorisations) différents. Flux sont des façons de récupérer un jeton d’accès. Le choix d’un flux le mieux adapté pour votre cas d’utilisation dépend surtout de votre application type (type d’application), mais d’autres paramètres entrent également en ligne de compte, comme le niveau de confiance vis-à-vis du client ou l’expérience que vous souhaitez offrir à vos utilisateurs.

• Resource Owner (Propriétaire de ressource) : Une entité pouvant accorder l’accès à une ressource protégée. Il s’agit généralement de l’utilisateur final.

• Client  : Application demandant l’accès à une ressource protégée au nom du propriétaire de ressource.

• Resource Server (Serveur de ressources) : Serveur hébergeant les ressources protégées. Il s’agit de l’API à laquelle vous souhaitez accéder.

• Authorization Server (Serveur d’autorisations) : Serveur qui identifie le propriétaire de la ressource et émet les jetons d’accès après réception d’une autorisation en bonne et due forme. Dans ce cas, 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).

Il convient tout d’abord de déterminer si la personne demandant l’accès à la ressource est une machine. Dans le cas d’une autorisation machine-machine, le client est également le propriétaire de la ressource, et ainsi donc aucune autorisation n’est requise. Exemple : tâche Cron utilisant une API pour importer l’information dans une base de données. Dans cet exemple, la tâche Cron est le client et le propriétaire de la ressource puisqu’il détient l’ID client et le secret client et les utilise pour obtenir un jeton d’accès auprès du serveur d’autorisations.

Si ce cas vous concerne, et que vous souhaitez en savoir plus sur ce flux et comment l’implémenter, lisez l’article Flux des identifiants client.

Si le client est une application web classique s’exécutant sur le serveur, alors le Flux Code d’autorisation est celui que vous devez utiliser. Ainsi, le client peut récupérer un jeton d’accès et, optionnellement, un jeton d’actualisation. On considère qu’il s’agit du choix le plus sécurisé, puisque le jeton d’accès est transmis directement au serveur web hébergeant le client, cela sans passer par le navigateur de l’utilisateur et donc sans risquer d’être exposé.

Si ce cas vous concerne, et que vous souhaitez en savoir plus sur ce flux et comment l’implémenter, lisez l’article Flux de code d’autorisation.

Ce point de décision peut amener à l’octroi d’identifiants de mot de passe du propriétaire de ressource. Dans ce flux, on demande à l’utilisateur final de renseigner ses identifiants (nom d’utilisateur/mot de passe), typiquement en utilisant un formulaire interactif. Cette information est envoyée au système dorsal, et de là, à Auth0. Il est donc impératif pouvoir faire confiance au client.

Cette autorisation ne doit être utilisé que lorsque les flux de redirection (comme le flux de code d’autorisation) ne sont pas possible. Si ce cas vous concerne et que vous souhaiter en savoir plus sur ce flux et comment l’implémenter, lisez l’article Flux de mot de passe du propriétaire de ressource .

Si le Client est une application à page unique (SPA), une application fonctionnant dans un navigateur avec un langage script comme JavaScript, il existe deux options d’autorisation : le Flux de code d’autorisation avec Proof Key for Code Exchange (PKCE) et le Flux implicite avec Form Post. Dans la majorité des cas, nous recommandons d’utiliser le flux de code d’autorisation avec PKCE car son jeton d’accès n’est pas exposé du côté client et parce que ce flux peut renvoyer des Jetons d’actualisation.

Pour savoir plus sur le fonctionnement de ce flux et pourquoi vous devriez l’implémenter, consultez l’article Flux de code d’autorisation avec Proof Key for Code Exchange (PKCE). La trousse SDK pour applications à page unique d’Auth0 offre une API de haut niveau pour implémenter un flux de code d’autorisation avec PKCE dans les applications à page unique.

Si votre application à page unique n’a pas besoin de jeton d’accès, vous pouvez utiliser le Flux implicite avec formulaire Post Pour savoir plus sur le fonctionnement de ce flux et pourquoi vous devriez l’implémenter, consultez l’article Implicit Flow with Form Post (Flux implicite avec Form Post).

Si l’application est native, utilisez le Flux de code d’autorisation avec Proof Key for Code Exchange (PKCE).

Pour savoir plus sur le fonctionnement de ce flux et pourquoi vous devriez l’implémenter, consultez l’article Flux de code d’autorisation avec Proof Key for Code Exchange (PKCE).

Si une application unique a besoin de jetons d’accès pour différents serveurs de ressources, plusieurs appels à /authorize (c’est-à-dire plusieurs exécutions du même flux d’autorisation ou de flux différents) doivent être effectués. Chaque autorisation utilisera une valeur différente pour le audience, ce qui se traduira par un jeton d’accès différent à la fin du flux. Pour plus d’informations, consultez l’article OAuth 2.0 : Spécifications sur les informations de l’audience.

Bien sûr ! Vous pouvez utiliser notre extension Authentication API Debugger (Débogueur d’API Authentication) Vous trouverez des instructions détaillées par point de terminaison /grant dans Authentication API Reference (Référence concernant l’API d’authentification).

• Pour en savoir plus sur le point de terminaison Authorize, allez à la section Authorize Application (Autoriser une application) et lisez le paragraphe « Tester ce point de terminaison » () pour l’autorisation que vous souhaitez tester.

• Pour en savoir plus sur le point de terminaison Jeton, allez à la section Get Token (Obtenir un jeton) et lisez le paragraphe « Tester ce point de terminaison » () pour l’autorisation que vous souhaitez tester.

L’authentification par canal arrière initiée par le client (CIBA) est une norme de la OpenID Foundation pour mettre en œuvre un flux d’authentification alternatif à OpenID Connect. CIBA diffère du flux standard d’OpenID Connect en ce que :

• L’application cliente initie le processus d’authentification au nom de l’utilisateur final.

• Pour interagir avec un utilisateur, il n’est pas nécessaire d’utiliser un navigateur.

• La communication entre l’application cliente et le fournisseur OpenID est directe.

CIBA est utile lorsque l’utilisateur ne fait pas confiance à l’application cliente, lorsque l’application cliente n’a pas de navigateur, ou lorsque l’utilisateur n’est pas devant l’application nécessitant une authentification. Voici quelques exemples d’endroits où les flux CIBA peuvent être utilisés :

• Enregistrement des utilisateurs à un terminal de vente au détail : Pour des scénarios de collecte par clic, un utilisateur peut s’authentifier auprès d’un kiosque public et confirmer sa présence.

• Authentification dans un centre d’appels ou au bureau d’un commis : Un agent de centre d’appels peut initier un processus d’authentification pour authentifier un appelant, généralement en utilisant une application mobile personnalisée sur un téléphone intelligent.

• Authentification sur un appareil sans entrée : Par exemple, un haut-parleur intelligent (ou un autre appareil connecté) peut utiliser un service dorsal pour contacter l’utilisateur pour une authentification, généralement en utilisant une application mobile personnalisée sur un téléphone intelligent.

CIBA définit deux types de dispositifs :

• Dispositif de consommation : Il s’agit du dispositif qui permet à l’utilisateur de consommer un service

• Dispositif d’authentification : Le dispositif sur lequel l’utilisateur s’authentifiera et donnera son consentement.

Pour en savoir plus, lisez Flux d’authentification par canal d’appui initié par le client.