Comment fonctionne OAuth · Cartes mentales
Comment fonctionne OAuth. Une carte mentale modifiable avec des branches colorées, des idées secondaires et des liens. Les courbes montrent les liens; les flèches indiquent les relations où le sens compte.
OAuth permet à une application d'accéder aux données d'un autre service au nom d'un utilisateur sans jamais voir le mot de passe de l'utilisateur, en échangeant son consentement contre un jeton de courte durée.
Comment fonctionne OAuth · Cartes mentales
Le canevas MindMap 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 cette carte mentale
- Commencez par le sujet central, puis suivez une branche colorée pour explorer ses idées.
- Les courbes montrent les liens; les flèches indiquent les relations où le sens compte.
User consent
Cette branche rassemble “User clicks “Sign in with provider””, “The consent screen is the step most real flows hide: the user chooses exactly which permissions the app may use, such as “read profile” but not “post”.”.
Redirect & code
Cette branche rassemble “The redirect carries the client id, the requested scopes and a redirect URI. The user never hands their password to the client application.”, “Authorization server returns an authorization code to the client”.
Token exchange
Cette branche rassemble “The code is short-lived and useless by itself. The exchange proves the client is who it claims to be by presenting its registered client secret.”, “Authorization server issues the access token”.
Resource access
Cette branche rassemble “Access tokens expire after a short window. Long-lived sessions use a separate refresh token that can mint new access tokens without asking the user again.”, “Resource server validates the token and returns the user's data”, “User sees their data inside the app”.
Liens entre les branches
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.
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
Adapter le sujet central
Renommez le sujet pour votre projet ou votre cours.
Développer les branches
Modifiez les idées et ajoutez des exemples ou des notes.
Relier les idées
Reliez les branches; utilisez une flèche lorsque le sens est important.
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 cette carte mentale dans QueryChart
Ouvrez cette carte mentale sur un espace modifiable. Déplacez les idées et ajoutez des branches et des liens.