Exemple de diagramme de séquence : le flux OAuth 2.0 Authorization Code avec PKCE

Un diagramme d'architecture montre qui parle à qui. Il ne peut pas montrer dans quel ordre, ni qui attend qui, et pour beaucoup de problèmes, c'est justement cet ordre qui compte. Les flux de connexion en sont l'exemple classique : les mêmes cinq messages dans un autre ordre deviennent une faille de sécurité.

Ce guide enseigne la notation des diagrammes de séquence sur un flux que la plupart des ingénieurs rencontrent tôt ou tard : une application monopage qui connecte un utilisateur avec le flux OAuth 2.0 Authorization Code et PKCE, puis appelle une API.

Ce que montre un diagramme de séquence

Le temps s'écoule vers le bas. Chaque participant a une ligne de vie, une boîte avec un trait en tirets en dessous, et chaque message est une flèche horizontale de l'émetteur vers le destinataire. Lire de haut en bas donne l'ordre des événements ; lire de gauche à droite indique qui intervient à chaque étape.

La notation, d'après la spécification UML 2.5.1 :

Le flux : Authorization Code avec PKCE

Une application monopage est un client public : tout ce qu'elle envoie au navigateur peut être lu, elle ne peut donc pas garder de secret client. PKCE, défini dans la RFC 7636, protège malgré tout le code d'autorisation : l'application prouve que celui qui échange le code est la même instance que celle qui a lancé le flux. Les bonnes pratiques actuelles de sécurité OAuth 2.0, la RFC 9700, imposent PKCE aux clients publics, le recommandent à tous les autres et indiquent que les clients ne devraient pas utiliser l'implicit grant.

Les étapes :

1. L'utilisateur sélectionne Se connecter.
2. L'application crée un code verifier et un challenge. Le code_verifier est une chaîne aléatoire de 43 à 128 caractères. Le code_challenge vaut BASE64URL(SHA256(code_verifier)), la méthode S256. L'application stocke aussi un state aléatoire.
3. L'application envoie le navigateur vers le point de terminaison d'autorisation avec le challenge :

GET /authorize?response_type=code
    &client_id=orders-spa
    &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
    &scope=orders.read
    &state=af0ifjsldkj
    &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
    &code_challenge_method=S256 HTTP/1.1
Host: auth.example.com

4. Le serveur d'autorisation connecte l'utilisateur et demande son consentement.
5. Il redirige vers la redirect_uri avec un code de courte durée et le même state.
6. L'application vérifie le state par rapport à la valeur stockée.
7. L'application échange le code auprès du point de terminaison de jeton, en envoyant le verifier qu'elle a conservé :

POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
&client_id=orders-spa&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

8. Le serveur d'autorisation hache le verifier et compare le résultat avec le challenge de l'étape 3. S'ils correspondent, il renvoie un jeton d'accès, et un jeton de rafraîchissement s'il en émet.
9. L'application appelle l'API avec Authorization: Bearer <access token>.
10. L'API valide le jeton, par exemple sa signature, son émetteur, son audience, son expiration et sa portée, puis répond.

Le verifier et le challenge ci-dessus sont les valeurs d'exemple de la RFC 7636 : vous pouvez donc vérifier vous-même le calcul S256.

Le diagramme

Comment le lire :

• Quatre participants sur une ligne : l'utilisateur comme acteur, puis les lignes de vie de l'application web, du serveur d'autorisation et de l'API. Chaque message est une flèche horizontale à sa propre hauteur, numérotée dans l'ordre.
• Les messages 2 à 7 forment le flux Authorization Code. Les notes montrent les deux vérifications qui le rendent sûr : l'application compare le state après la redirection, et le serveur d'autorisation compare le verifier haché avec le challenge.
• Les messages 8 et 9 sont l'appel d'API. Les réponses sont en tirets avec des pointes de flèche ouvertes.
• Le fragment opt couvre le cas où le jeton d'accès a expiré : un 401, un rafraîchissement et une nouvelle tentative.

Montrer le chemin d'échec, pas seulement le chemin nominal

La plupart des diagrammes de séquence s'arrêtent à « 200 OK ». Les bugs intéressants vivent dans les branches : dessinez donc au moins celle qui se produit tous les jours. Utilisez alt quand le diagramme montre plusieurs branches mutuellement exclusives, chacune avec une garde, et opt pour une partie qui ne s'exécute que si sa garde est vraie. Le rafraîchissement ici est un opt : il n'a lieu que lorsque le jeton d'accès a expiré.

La branche de rafraîchissement a ses propres règles. Dans les applications web, les jetons de rafraîchissement sont généralement des bearer tokens ; la RFC 9700 et la RFC 10017, les bonnes pratiques pour les applications dans le navigateur publiées en août 2026, exigent donc que le serveur d'autorisation les renouvelle à chaque utilisation ou les lie au client, et qu'il limite leur durée de vie. C'est pour cette raison que le message 13 renvoie un nouveau jeton de rafraîchissement.

La RFC 10017 classe aussi les architectures d'applications web selon leur sécurité. Un backend-for-frontend qui garde les jetons côté serveur est la plus solide ; une application dans le navigateur qui joue elle-même le rôle de client OAuth, comme dans ce diagramme, est la plus simple et la plus exposée au JavaScript malveillant. Si vous choisissez ce modèle, le diagramme est un bon endroit pour expliquer pourquoi.

Les erreurs courantes dans les diagrammes de séquence

• Trop de lignes de vie. Au-delà de six ou sept, les libellés se chevauchent et le lecteur perd le fil. Découpez le flux, ou regroupez les services internes derrière une seule ligne de vie.
• Des réponses sans libellé. « Réponse » ne dit rien. Écrivez le statut ou le contenu : « 302 avec code », « 401 invalid_token ».
• Des niveaux de détail mélangés. Des paramètres HTTP sur une flèche et « l'utilisateur est content » sur la suivante perdent les deux publics. Choisissez un niveau et tenez-vous-y.
• Seulement le chemin nominal. Les timeouts, les nouvelles tentatives et les identifiants expirés sont précisément là où les diagrammes sont rentables.
• Tous les paramètres. Montrez ceux que le lecteur doit vérifier, comme state, code_challenge et code_verifier, et laissez le reste à la référence de l'API.

Quand l'utiliser, et quand s'en passer

Utilisez un diagramme de séquence pour les protocoles, les handshakes, les nouvelles tentatives, les timeouts, les situations de concurrence et les chronologies d'incidents : tout ce où l'ordre et l'attente comptent. Choisissez autre chose pour la structure statique (un diagramme d'architecture ou C4), pour la diffusion d'événements vers de nombreux consommateurs (un diagramme d'architecture orientée événements) et pour les revues de sécurité qui montrent où les données franchissent des frontières de confiance (un diagramme de flux de données pour la modélisation des menaces).

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Depuis le pack Séquence, ajoutez un Acteur pour l'utilisateur et trois nœuds Ligne de vie pour l'application web, le serveur d'autorisation et l'API, sur une même ligne et à la même hauteur.
3. Dessinez chaque message comme un lien droit entre deux lignes de vie, de haut en bas, avec un libellé numéroté. Passez les réponses en tirets.
4. Ajoutez un Fragment combiné autour des messages 10 à 14, réglez son opérateur sur opt et son libellé sur « [access token expired] ».
5. Ajoutez des nœuds Note du pack UML pour les vérifications : le state, le verifier haché et la validation du jeton.

L'exemple utilise 5 nœuds de diagramme et reste dans les limites de l'offre Free. Le serveur MCP d'Archboard connecte lui-même les applications d'IA avec ce flux, l'authorization code grant avec PKCE (S256) ; consultez comment créer des diagrammes d'architecture avec des agents IA.

FAQ

PKCE est-il réservé aux applications mobiles ? Non. Il a été conçu pour les applications natives, mais la RFC 9700 l'impose à tous les clients publics, y compris les applications monopages, et le recommande aussi aux clients confidentiels.

Une application monopage doit-elle utiliser le flux implicite ? Non. La RFC 9700 indique que les clients ne devraient pas utiliser l'implicit grant. Utilisez le flux Authorization Code avec PKCE.

OAuth 2.1 est-il un standard finalisé ? Pas au moment où nous écrivons (octobre 2026). C'est toujours un Internet-Draft de l'IETF qui regroupe OAuth 2.0 et ses pratiques de sécurité, dont PKCE.

Quelle est la différence entre alt et opt ? alt contient au moins deux branches mutuellement exclusives, chacune avec une garde. opt contient une seule partie qui ne s'exécute que si sa garde est vraie.

Combien de messages tiennent dans un diagramme de séquence ? Autant qu'il en reste lisibles à la taille où les gens le regardent, généralement 15 à 20. Découpez les flux plus longs en plusieurs diagrammes, un par phase.

Commencez gratuitement — un siège, sans carte bancaire.