Comment fonctionne OAuth : flux de code d'autorisation

Comment fonctionne OAuth : flux de code d'autorisation

Le canevas FlowJam interactif de cette explication : chaque couloir, ligne et flèche ci-dessus appartient à un véritable diagramme QueryChart que vous pouvez ouvrir et modifier.

Comment lire ce visuel

• Lisez les trois colonnes de gauche à droite : Autorisation, Échange de jetons, Ressource protégée.
• Chaque ligne représente la partie de l'histoire d'une partie : la ligne de l'utilisateur se trouve en haut et celle du serveur de ressources en bas, de sorte que le consentement de l'utilisateur et la validation du serveur se situent au milieu.
• Les flèches qui sautent des lignes, comme le code renvoyé au client, sont de véritables messages réseau entre les parties ; les flèches dans une rangée représentent les propres pas de cette partie.

La danse des autorisations

"L'utilisateur clique sur "Connexion avec le fournisseur"" commence dans la ligne de l'utilisateur et passe à "Le client redirige l'utilisateur vers le serveur d'autorisation". La redirection est le mouvement déterminant d'OAuth : elle fait sortir l'utilisateur de l'application client vers le fournisseur, où "l'utilisateur se connecte et approuve les étendues demandées" se produit. L'écran de consentement (pas seulement la connexion) est l'étape qui compte : l'utilisateur choisit exactement ce que le client peut faire. "Le serveur d'autorisation renvoie un code d'autorisation au client" redonne le contrôle à l'application, mais uniquement avec un code, pas un jeton.

L'échange de jetons

"Le client échange le code et son secret contre un jeton d'accès" passe de la ligne client à celle du serveur d'autorisation. Cette étape est celle où le client prouve qu'il s'agit d'une application légitime en présentant le code qu'il a reçu ET son secret client enregistré, donc un code volé à lui seul ne suffit pas. « Le serveur d'autorisation émet le jeton d'accès » est le moment où la décision de consentement devient une capacité : une chaîne qui indique ce que le client peut faire, pendant combien de temps.

Dépenser le jeton

"Le client appelle le serveur de ressources avec le jeton d'accès" passe dans le cluster "Serveur de ressources", et "Le serveur de ressources valide le jeton et renvoie les données de l'utilisateur" est la récompense. Le serveur de ressources ne voit jamais le mot de passe de l'utilisateur ni l'écran de consentement : il vérifie uniquement le jeton. « L'utilisateur voit ses données à l'intérieur de l'application » ferme la boucle dans la ligne de l'utilisateur : du point de vue de l'utilisateur, il s'est connecté une fois et l'application a obtenu ses données.

Relations et enseignements clés

• Le mot de passe de l'utilisateur est donné uniquement au serveur d'autorisation : le client et le serveur de ressources ne le voient jamais.
• Le consentement (les portées) est l'octroi réel ; le jeton d'accès est cette autorisation sous une forme lisible par machine.
• Le code d'autorisation est éphémère et inutile sans le secret client : deux facteurs protègent l'échange.
• Les jetons d'accès expirent ; actualisez les jetons et créez-en de nouveaux tranquillement sans un autre écran de consentement.
• La seule tâche du serveur de ressources consiste à valider le jeton, ce qui maintient les parties découplées.

Quand utiliser ce visuel

• Expliquer à une équipe produit pourquoi « Se connecter avec Google » est sécurisé et ce que demande l'écran de consentement.
• Choisir un flux OAuth : le flux de code d'autorisation ici par rapport aux informations d'identification implicites ou client pour d'autres scénarios.
• Vérifier où les informations d'identification et les jetons des utilisateurs voyagent réellement dans votre intégration.

Comment cela fonctionne

1. Renommez les parties de votre système

   Remplacez les quatre clusters par vos vrais participants (votre application Web, votre fournisseur d'identité, votre API) afin que les limites reflètent le système que vous documentez.

2. Ajoutez les étendues que vous demandez

   Annotez l'étape de consentement avec les étendues réelles et une note expliquant pourquoi chacune est nécessaire, afin que les réviseurs puissent voir la décision de moindre privilège.

3. Dessinez le chemin de rafraîchissement

   Ajouter une branche après l'expiration du jeton : le client présente le jeton d'actualisation et reçoit un nouveau jeton d'accès sans écran de consentement, se terminant par son propre état explicite.

4. Modéliser les cas de défaillance

   Ajoutez les branches de rejet (un écran de consentement refusé, un code invalide, un jeton expiré ou révoqué) chacune avec la réponse d'erreur qu'elle produit.

Questions fréquentes

Qu’est-ce qu’OAuth et pourquoi existe-t-il ?

OAuth est une norme de délégation. Il permet à une application d'accéder aux données d'un utilisateur sur un autre service au nom de l'utilisateur sans que l'application ne voie le mot de passe de l'utilisateur. L'utilisateur s'authentifie une fois auprès du serveur d'autorisation et approuve des autorisations spécifiques (portées) ; l'application reçoit un jeton qu'elle peut dépenser. Cette séparation des préoccupations est exactement ce que représentent les quatre groupes du visuel.

Quelle est la différence entre un code d'autorisation et un jeton d'accès ?

Un code d'autorisation est une valeur intermédiaire de courte durée que le client reçoit après le consentement de l'utilisateur ; à lui seul, il n’apporte rien. Le client échange le code (ainsi que son secret client enregistré) contre un jeton d'accès, qui est la capacité réelle utilisée pour appeler le serveur de ressources. L'échange en deux étapes permet au client de prouver son identité au point final du jeton.

Pourquoi l’utilisateur ne donne-t-il pas son mot de passe à l’application ?

Parce que l'application n'a besoin que d'un accès limité et révocable : lire un profil, pas posséder de compte. Si l'application recevait le mot de passe, elle bénéficierait d'un accès complet pour toujours et l'utilisateur ne pourrait pas révoquer une application sans changer son mot de passe partout. OAuth échange un mot de passe contre un jeton limité et expirant que l'utilisateur peut révoquer indépendamment.

Que sont les portées ?

Les étendues sont les autorisations spécifiques accordées par l'utilisateur, telles que « lire le courrier électronique » ou « écrire dans le calendrier ». Ils apparaissent sur l'écran de consentement et sont codés dans le jeton d'accès. Le serveur de ressources les applique, donc un jeton limité à la lecture ne peut pas écrire : le moindre privilège est intégré au protocole plutôt que de compter sur le bon comportement du client.

Modifier ce visuel dans QueryChart (FlowJam)

Ouvrez ce canevas de flux OAuth exact en tant que votre propre graphique, renommez les parties à vos services et annotez les étendues que vous demandez.

Modifier ce visuel dans QueryChart (FlowJam)