Si le mot de passe est mort, par quoi le remplacer ? La première étape, c’est de ne plus le gérer vous-même. C’est le principe de la délégation.

L’analogie du Voiturier

Pour comprendre OAuth2, imaginez un voiturier dans un grand hôtel :

1. Je lui donne ma clé de voiture (Mes credentials Google).
2. Il me donne un ticket (Authorization Code).
3. Plus tard, je donne ce ticket au guichet pour récupérer ma voiture (Access Token).
4. Le guichet n’a jamais vu ma clé de voiture. Il a juste vu le ticket.

AuthN vs AuthZ : La confusion éternelle

C’est la distinction fondamentale que beaucoup de développeurs confondent.

• Authentication (AuthN) : “Qui êtes-vous ?” C’est la vérification de l’identité. Comme présenter son passeport à la douane.
  • Protocole : OpenID Connect (OIDC).
  • Artefact : ID Token. C’est une preuve d’identité signée. Il dit “C’est bien Jean-Michel qui est connecté”.
• Authorization (AuthZ) : “Que pouvez-vous faire ?” C’est la permission d’accéder à une ressource. Comme un badge d’accès qui ouvre certaines portes mais pas d’autres, ou un billet de concert.
  • Protocole : OAuth2.
  • Artefact : Access Token. C’est une clé temporaire. Il dit “Cette appli a le droit d’accéder à mes photos (mais pas de les supprimer)”.

Pourquoi la confusion ? Parce que souvent, quand on utilise OAuth2 (pour l’autorisation), on s’authentifie d’abord. Mais OAuth2 seul ne devrait pas servir à l’authentification (c’est comme utiliser une clé de voiture comme carte d’identité : ça prouve que vous avez la clé, pas que vous êtes le propriétaire). C’est pour cela qu’OIDC a été créé : pour ajouter la couche d’identité standardisée qui manquait à OAuth2.

Le Flow sécurisé (Authorization Code Flow + PKCE)

En 2025, oubliez l’Implicit Flow. Voici le standard sécurisé pour une Web App :

1. User clique sur “Login with Google”.
2. App redirige vers Google avec un client_id et un code_challenge (PKCE).
3. User s’authentifie chez Google.
4. Google renvoie un code temporaire.
5. App échange ce code + code_verifier contre un ID Token (JWT) et un Access Token.
6. App utilise l’ID Token pour savoir qui est l’utilisateur (AuthN).
7. App utilise l’Access Token pour accéder aux ressources (AuthZ).

Plongée dans le JWT (JSON Web Token)

Le JWT est le standard pour échanger ces informations. Il est composé de trois parties séparées par des points (.) : Header.Payload.Signature.

Exemples d’ID Token et Access Token

ID Token (AuthN - Identité) Il répond à “Qui suis-je ?”.

{
  "iss": "https://accounts.google.com", // Emetteur
  "sub": "10987654321",                 // Sujet (ID User unique)
  "aud": "votre-client-id",             // Audience (Pour qui est ce token ?)
  "email": "alice@example.com",         // Claims d'identité
  "iat": 1716238000,                    // Issued At
  "exp": 1716239000                     // Expiration
}

Access Token (AuthZ - Autorisation) Il répond à “Quels sont mes droits ?”.

{
  "iss": "https://api.mon-app.com",
  "sub": "10987654321",
  "scope": "read:photos write:profile", // Les permissions accordées
  "aud": "https://api.mon-app.com/v1",
  "exp": 1716242600
}

Signature vs Chiffrement (JWS vs JWE)

Attention à la confusion !

• JWS (Signed) : La majorité des JWT. Le contenu est lisible par tout le monde (juste encodé en Base64), mais signé cryptographiquement. Si vous modifiez un caractère, la signature devient invalide.
  • Règle d’or : Ne jamais mettre de données sensibles (mots de passe, secrets bancaires) dans un JWS !
• JWE (Encrypted) : Le contenu est chiffré. Seul le destinataire possédant la clé privée peut le lire. C’est plus rare mais utile pour la confidentialité.

Outils de vérification

Pour debugger, l’outil incontournable est jwt.io. Il permet de décoder le Base64 et de vérifier la signature si vous avez la clé publique/secrète.

• Note : Ne collez jamais de vrais tokens de production sur des sites tiers !

Analyse des Menaces (Modèle STRIDE)

Pour résumer les risques abordés, appliquons le modèle STRIDE à OAuth2/OIDC :

Menace (STRIDE)	Description	Attaque	Contre-mesure
Spoofing (Usurpation)	Se faire passer pour un autre utilisateur.	Faille “Sign in with Apple” (Token forgé).	Validation stricte de la signature et de l’émetteur (iss).
Tampering (Modification)	Modifier les droits dans le token.	Algorithme “None” (Admin access).	Refuser alg: none, vérifier la signature JWS.
Repudiation	Nier avoir effectué une action.	(Moins spécifique ici)	Logs d’audit des émissions de tokens.
Information Disclosure	Vol de données sensibles.	Vol de Token via XSS ou Man-in-the-Middle.	HTTPS, HttpOnly Cookies, JWE (Chiffrement).
Denial of Service	Rendre le service indisponible.	Surcharge via demandes de tokens massives.	Rate Limiting sur l’endpoint /token.
Elevation of Privilege	Gagner des droits non autorisés.	Login CSRF (Vol de session).	Paramètre state et PKCE.

Attaques courantes sur les JWT

L’implémentation d’OAuth2/OIDC est complexe et les erreurs sont fatales.

• Fuite d’informations : Comme le payload est lisible, un attaquant qui intercepte le token (Man-in-the-Middle) peut lire toutes les infos personnelles s’il n’est pas chiffré.
• Vol de Token (XSS) : Si un attaquant exécute du JS sur votre page, il peut voler les tokens stockés dans le navigateur.

L’attaque CSRF (Login CSRF)

• Le scénario : Un attaquant initie une connexion avec son compte Google, récupère le code d’autorisation, mais ne le valide pas. Il envoie un lien piégé à la victime. La victime clique, et son navigateur envoie le code de l’attaquant à l’application.
• Le résultat : La victime est connectée… sur le compte de l’attaquant ! Si elle saisit sa carte bancaire, elle l’enregistre sur le compte du pirate.
• La parade : Le paramètre state. C’est une chaîne aléatoire générée par le client avant la redirection et vérifiée au retour. Si le state ne correspond pas, on rejette la requête.

Validation du JWT : L’affaire “Sign in with Apple” (2020)

• L’histoire : Le chercheur Bhavuk Jain a découvert une faille critique (payée 100 000$) dans le système d’Apple. Il pouvait demander un JWT pour n’importe quelle adresse email à Apple, et Apple le signait validement !
• La leçon : Même les géants font des erreurs. Côté client, vous devez impérativement vérifier :
  1. La Signature : Le token a-t-il été modifié ?
  2. L’émetteur (iss) : Est-ce bien Google/Apple qui l’a émis ?
  3. L’audience (aud) : Ce token est-il bien pour mon application ? (Sinon, un site malveillant pourrait utiliser un token valide obtenu légitimement pour se connecter chez vous).
  4. L’expiration (exp) : Le token est-il encore valide ?

L’algorithme “None”

• Le hack : Certains validateurs JWT acceptaient l’algorithme none dans le header ({"alg": "none"}). L’attaquant pouvait alors forger un token admin sans signature, et le backend l’acceptait comme valide.
• La parade : Configurez votre librairie JWT pour refuser explicitement l’algorithme none.

Où stocker les tokens ? (Best Practices OWASP)

C’est le débat éternel : LocalStorage vs Cookies vs Headers.

• LocalStorage :
  • Avantage : Facile à utiliser en JS (localStorage.setItem).
  • Risque : Vulnérable aux failles XSS. Tout script malveillant peut lire localStorage.
  • Verdict OWASP : Déconseillé pour les tokens sensibles.
• HttpOnly Cookies :
  • Avantage : Le JS ne peut pas lire le cookie. Immunisé contre le vol par XSS.
  • Inconvénient : Moins de contrôle côté client pour l’envoi des tokens.
  • Risque : Vulnérable aux attaques CSRF (mais on peut s’en prémunir avec SameSite=Strict et des tokens anti-CSRF).
  • Verdict OWASP : Recommandé. Stockez vos tokens (surtout le Refresh Token) dans des cookies Secure, HttpOnly et SameSite.
• Dans les headers :
  • Avantage : Contrôle total sur l’envoi des tokens.
  • Inconvénient : Nécessite de stocker temporairement en mémoire (ex: variables JS) ou dans des structures sécurisées (complexe).
  • Risque : Nécessite une gestion fine côté client pour éviter les fuites.
  • Verdict OWASP : Acceptable si bien géré.

Référence : OWASP JSON Web Token Cheat Sheet et HTML5 Security Cheat Sheet.

Ressources et Cheat Sheets (OWASP)

Pour aller plus loin et sécuriser vos implémentations, référez-vous aux bibles de la sécurité :

• 🛡️ OWASP JWT Cheat Sheet : Lien
• 🛡️ OWASP OAuth 2.0 Threat Model : Lien
• 🛡️ RFC 7519 (JWT) : La spécification officielle.

Conclusion

OAuth2 et OIDC sont des outils puissants pour déléguer l’authentification et l’autorisation. En comprenant leurs différences et en suivant les bonnes pratiques de sécurité, vous pouvez offrir une expérience utilisateur fluide tout en protégeant vos applications contre les menaces courantes. N’oubliez pas : ne gérez plus les mots de passe vous-même, déléguez à des fournisseurs de confiance !

Dans le prochain article, nous irons encore plus loin : supprimer le mot de passe, même chez le fournisseur d’identité, grâce à FIDO2.