Visualiseur du flux OAuth 2.0 / OIDC à code d’autorisation avec PKCE

Visualiseur du flux OAuth 2.0 / OIDC à code d’autorisation avec PKCE | Outil en ligne gratuit | Elysia Tools

Guide d'utilisation de l'outil

Découvrez quand utiliser cet outil, ce qu'il prend en charge et comment les utilisateurs l'appliquent.

Points clés

Catégorie: Development
Types d’entrée: select, text, checkbox
Type de sortie: html
Exemples associés: 4
API disponible: Oui

Aperçu

Ce simulateur hors ligne modélise l'intégralité du flux d'autorisation OAuth 2.0 et OpenID Connect avec PKCE selon les spécifications RFC 7636 et OIDC Core §3.1.3.7. Il génère les challenges cryptographiques S256, compose l'URL d'autorisation, simule l'échange de token sur le canal arrière, valide les revendications du jeton d'identification (dont at_hash) et permet d'illustrer la protection contre les attaques par interception de code.

Quand l’utiliser

Pour comprendre et tester pas à pas la dérivation cryptographique PKCE (S256 ou plain) et la construction des requêtes d'autorisation.
Pour vérifier la conformité d'une implémentation OpenID Connect par rapport aux critères d'intégrité de l'ID Token (§3.1.3.7).
Pour démontrer les risques de sécurité d'un flux sans PKCE face à l'interception du code d'autorisation sur un client public.

Fonctionnement

1Configurez les paramètres du client (issuer, client_id, redirect_uri, scopes, secret de test) et choisissez la variante PKCE (S256, plain ou none).
2L'outil génère localement le code_challenge dérivé du code_verifier ainsi que les paramètres d'état (state, nonce) et construit l'URL de redirection.
3Le simulateur exécute l'échange de code contre des jetons et décode le JWT pour appliquer la liste de validation complète (iss, aud, signature, exp, at_hash).
4Le résultat HTML présente les étapes détaillées, la matrice des paramètres annotée et, si activé, le comportement d'un attaquant interceptant le code.

Cas d’usage

Formation et sensibilisation des développeurs à la sécurité des flux OAuth 2.0 / OIDC.
Débogage et inspection visuelle des paramètres requis lors de l'intégration d'un fournisseur d'identité.
Démonstration technique de la vulnérabilité d'interception de code et de son atténuation par PKCE.

Exemples

1. Flux nominal complet avec PKCE S256

Développeur frontend

Contexte

Intégration de l'authentification OpenID Connect sur une application monopage (SPA) sans stockage de secret client.

Problème

Vérifier la bonne formulation de la requête d'autorisation PKCE S256 et la validation de l'ID Token retourné.

Utilisation

Sélectionnez la variante 's256', renseignez les identifiants de test et lancez la simulation.

flowVariant=s256, issuer=http://127.0.0.1:8443, clientId=spa-demo-client, redirectUri=http://127.0.0.1:8080/callback, scope=openid profile email

Résultat

Génération de l'URL d'autorisation avec code_challenge S256 et validation réussie à 9/9 des critères OIDC Core (dont signature HS256 et at_hash).

2. Simulation d'attaque par interception sans PKCE

Ingénieur sécurité

Contexte

Audit d'une application utilisant l'ancien flux Authorization Code standard sans protection PKCE.

Problème

Mettre en évidence le risque d'échange non autorisé d'un code intercepté sur le canal frontal.

Utilisation

FAQ

Comment est calculé le code_challenge en mode S256 ?

Il s'obtient en appliquant un hachage SHA-256 sur le code_verifier, puis en encodant le résultat binaire en Base64URL sans remplissage (=).

Ce simulateur effectue-t-il des requêtes réseau réelles ?

Non, toutes les étapes, signatures HS256 et validations d'horodatage sont calculées localement de manière déterministe.

À quoi sert la vérification du paramètre at_hash dans l'ID Token ?

Le champ at_hash garantit que l'access_token délivré correspond précisément à l'ID Token émis lors de la même réponse.

Pourquoi la variante 'none' sans PKCE est-elle déconseillée pour les SPA ?

Sans PKCE, un tiers interceptant le code d'autorisation peut l'échanger sans prouver qu'il est l'initiateur légitime de la demande.

Quelle est la longueur requise pour le code_verifier PKCE ?

Selon la RFC 7636, le code_verifier doit comporter entre 43 et 128 caractères non réservés (A-Z, a-z, 0-9, -, ., _, ~).

flowVariant=none, clientId=spa-demo-client, simulateAttack=true, scope=openid

Ce que cet outil vous aide à faire

Exécuter cet outil

Exemples adaptés à cet outil

Continuer avec des outils et dossiers associés

Découvrez quand utiliser cet outil, ce qu'il prend en charge et comment les utilisateurs l'appliquent.

Points clés

Aperçu

Quand l’utiliser

Fonctionnement

Cas d’usage

Exemples

1. Flux nominal complet avec PKCE S256

2. Simulation d'attaque par interception sans PKCE

FAQ

Exemples de Commentaires de Code

Exemples OAuth 2.0 & OpenID Connect

Exemples de Codes QR

Exemples OAuth 2.0

Générateur de PKCE Code Verifier et Challenge

Generateur de phrases mnémoniques BIP39

Comparateur d’algorithmes de hachage

Générateur de puzzles Kakuro / Fillomino / Masyu / Yajilin / Hashiwokakero / Nurikabe / Slitherlink / Star Battle avec preuve d'unicité