OAuth : sécurité et attaques sur les flux d'auth

OAuth est un protocole d'autorisation standardisé (RFC 6749) permettant à une application tierce d'accéder à des ressources protégées au nom d'un utilisateur, sans exposer ses identifiants. OAuth délègue l'autorisation via des jetons d'accès (access tokens) émis par un Authorization Server. Les flux d'auth les plus courants sont Authorization Code, Implicit (déprécié), Client Credentials et Device Code. Chaque flux expose des surfaces d'attaque spécifiques : l'Authorization Code Flow reste le plus sécurisé mais reste vulnérable à l'interception du code via un redirect_uri mal validé. Le paramètre state, conçu pour prévenir le CSRF, est souvent absent ou prévisible. L'extension PKCE (Proof Key for Code Exchange) renforce la sécurité des clients publics en liant le code d'autorisation à un code_verifier secret. OAuth ne définit pas l'authentification : OpenID Connect (OIDC) comble ce manque en ajoutant un id_token signé. La confusion entre autorisation et authentification est elle-même un vecteur d'attaque fréquent en pentest d'applications web modernes.

Côté Blue Team, la détection des abus OAuth repose sur l'analyse des logs des Identity Providers (IdP) : Azure AD, Okta, Google Workspace exposent des événements d'octroi de consentement et d'émission de tokens. Dans Azure AD, l'événement 'Consent to application' (audit log category : ApplicationManagement) signale un consentement utilisateur, potentiellement forcé par du consent phishing. L'événement 'Add OAuth2PermissionGrant' indique une élévation de périmètre. Surveiller les redirect_uri inhabituelles ou non enregistrées dans les logs d'autorisation permet de détecter une tentative d'interception de code. Les SIEM comme Microsoft Sentinel disposent de règles analytiques dédiées aux applications OAuth suspectes (requêtes KQL sur SigninLogs et AuditLogs). Un access_token présentant une audience (aud) inattendue ou une durée de vie anormalement longue dans les logs API Gateway est un IOC fort. Les anomalies de volume de tokens émis pour un client_id donné, ou des refresh_tokens utilisés depuis des ASN inhabituels, méritent une investigation immédiate. Corréler ces événements avec les User-Agent strings permet de distinguer un client légitime d'un outil d'attaque automatisé.

En pentest, les attaques sur OAuth ciblent plusieurs points du flux d'auth. L'open redirect OAuth consiste à manipuler le redirect_uri pour exfiltrer le code d'autorisation vers un domaine contrôlé par l'attaquant, notamment lorsque la validation côté Authorization Server accepte des correspondances partielles. Le consent phishing exploite la possibilité d'enregistrer une application OAuth malveillante avec des permissions étendues (lecture de mails, accès OneDrive) pour obtenir un accès persistant sans compromettre de mot de passe. Le token leakage via le Referer HTTP survient lorsque l'access_token est transmis en fragment d'URL ou en paramètre de requête. L'attaque mix-up consiste à tromper un client OAuth pour qu'il envoie son code à un Authorization Server adverse. Pour le durcissement : imposer PKCE sur tous les clients publics, valider strictement les redirect_uri par correspondance exacte, révoquer les grants OAuth inutilisés, limiter la durée de vie des access_tokens (max 1 heure), activer la rotation des refresh_tokens et auditer régulièrement les consentements accordés via les rapports d'activité des IdP. Les outils BurpSuite (extension OAuth Scanner) et TokenTactics facilitent l'audit offensif de ces flux.