OAuth 2.0 et OpenID Connect : Décryptez l'Authentification et l'Autorisation pour vos Applications Web

À l'ère du web moderne, l'authentification et l'autorisation sont devenues omniprésentes. Dès que vous choisissez de « Continuer avec Google » ou de « Se connecter via GitHub » sur une application, vous activez les puissants mécanismes d'OAuth 2.0. Ce protocole incontournable de l'industrie gère l'autorisation d'accès aux ressources, tandis que son extension, OpenID Connect (OIDC), s'occupe de l'authentification. Maîtriser ces concepts est indispensable pour tout développeur web souhaitant bâtir des applications sécurisées et intégrées, offrant une expérience utilisateur fluide.

Authentification vs. Autorisation : Démêler les Concepts Clés

• Authentification (AuthN) : « Qui êtes-vous ? » — Il s'agit de la vérification de l'identité de l'utilisateur. C'est le rôle fondamental d'OpenID Connect.
• Autorisation (AuthZ) : « Que pouvez-vous faire ? » — C'est l'acte de concéder des permissions à une application. C'est la mission principale d'OAuth 2.0.

Conçu initialement pour l'autorisation, OAuth 2.0 permet par exemple à une application tierce d'accéder à vos documents Google Drive sans jamais révéler votre mot de passe Google. OpenID Connect, quant à lui, se superpose à OAuth pour introduire une couche d'authentification, offrant ainsi une méthode standardisée pour récupérer les informations d'identité de l'utilisateur de manière sécurisée.

Les Acteurs Clés du Processus

• Propriétaire de la Ressource : L'utilisateur final qui possède les données ou les ressources protégées (c'est-à-dire vous).
• Client : L'application tierce qui souhaite accéder aux ressources protégées en votre nom.
• Serveur d'Autorisation : La plateforme qui authentifie le propriétaire de la ressource et émet les jetons (tokens) d'accès. Exemples : Google, GitHub, Auth0.
• Serveur de Ressource : L'API qui héberge les données protégées auxquelles le client souhaite accéder (ex: l'API Google Drive, l'API GitHub).

Flux de Code d'Autorisation (avec PKCE) : La Méthode Recommandée

Ce flux est unanimement recommandé pour les applications web traditionnelles et les Single Page Applications (SPA). PKCE (Proof Key for Code Exchange) est une extension cruciale qui renforce la sécurité en prévenant les attaques par interception du code d'autorisation, notamment pour les clients publics.

1. L'utilisateur clique sur « Se connecter avec Google » depuis votre application.
2. Votre application redirige l'utilisateur vers le point de terminaison d'autorisation de Google :
   GET https://accounts.google.com/o/oauth2/v2/auth?
     response_type=code
     &client_id=YOUR_CLIENT_ID
     &redirect_uri=https://yourapp.com/callback
     &scope=openid email profile
     &state=random_csrf_token
     &code_challenge=SHA256_HASH
     &code_challenge_method=S256

3. L'utilisateur se connecte à Google et accorde les permissions demandées.
4. Google redirige l'utilisateur vers votre application avec un code d'autorisation :
   GET https://yourapp.com/callback?code=AUTH_CODE&state=random_csrf_token

5. Votre serveur échange ce code contre des jetons (tokens) :
   POST https://oauth2.googleapis.com/token
   Body: {
     code: AUTH_CODE,
     client_id: YOUR_CLIENT_ID,
     client_secret: YOUR_CLIENT_SECRET,
     redirect_uri: https://yourapp.com/callback,
     grant_type: authorization_code,
     code_verifier: ORIGINAL_RANDOM_STRING
   }

6. Google renvoie les jetons suivants :
   {
     "access_token": "ya29.a0...",
     "id_token": "eyJhbGci...",       // Spécifique à OpenID Connect
     "refresh_token": "1//0e...",
     "expires_in": 3600,
     "token_type": "Bearer"
   }

Comprendre les Différents Jetons (Tokens)

• Jeton d'Accès (Access Token) : De courte durée (généralement 1 heure). Il permet d'appeler les APIs du serveur de ressource au nom de l'utilisateur. Il doit être inclus dans l'en-tête HTTP Authorization: Bearer <jeton>.
• Jeton de Rafraîchissement (Refresh Token) : De longue durée. Utilisé pour obtenir de nouveaux jetons d'accès sans nécessiter une nouvelle authentification de l'utilisateur. Il doit être stocké de manière ultra-sécurisée (côté serveur uniquement, jamais dans le localStorage du navigateur).
• Jeton d'Identité (ID Token) : Un JSON Web Token (JWT) contenant les informations d'identité de l'utilisateur (email, nom, photo de profil, etc.). C'est l'apport essentiel d'OpenID Connect à OAuth 2.0.

Les Scopes : Définir les Permissions Demandées

Les scopes (ou étendues) sont des identifiants qui définissent précisément les permissions que votre application souhaite obtenir. L'utilisateur les visualise et les approuve (ou non) sur l'écran de consentement du serveur d'autorisation.

// Scopes OpenID Connect
openid        // Indispensable pour OIDC
email         // Adresse e-mail de l'utilisateur
profile       // Nom, photo de profil, langue

// Scopes spécifiques à Google
https://www.googleapis.com/auth/drive.readonly
https://www.googleapis.com/auth/calendar

// Scopes GitHub
read:user     // Lecture du profil utilisateur
repo          // Accès complet aux dépôts
read:org      // Lecture de l'adhésion à l'organisation

Bonnes Pratiques de Sécurité Indispensables

• Toujours utiliser PKCE : Même pour les applications côté serveur, PKCE est une couche de sécurité supplémentaire. Il est impératif pour les clients publics (SPA, applications mobiles).
• Valider le paramètre state : Cette étape est cruciale pour prévenir les attaques CSRF (Cross-Site Request Forgery).
• Ne jamais stocker les jetons dans le localStorage : Préférez l'utilisation de cookies HTTP-only, sécurisés (Secure) et avec l'attribut SameSite.
• Valider les jetons d'identité (ID Tokens) : Vérifiez systématiquement l'émetteur (issuer), l'audience (audience), la date d'expiration et la signature.
• Demander le minimum de scopes : N'accordez à votre application que les permissions strictement nécessaires à son fonctionnement.
• Utiliser des jetons d'accès de courte durée avec rotation des jetons de rafraîchissement : Cela limite la fenêtre d'opportunité en cas de compromission.

Quel Flux Choisir et Quand ?

• Code d'Autorisation + PKCE : Applications web traditionnelles, Single Page Applications (SPA), applications mobiles. C'est le choix par défaut, le plus sûr et le plus recommandé.
• Client Credentials (Identifiants Client) : Pour la communication de serveur à serveur, lorsque aucun utilisateur final n'est impliqué. L'application agit en son propre nom.
• Code Appareil (Device Code) : Adapté aux appareils avec des capacités d'entrée limitées, comme les Smart TV, les interfaces en ligne de commande (CLI) ou les appareils IoT.
• ⚠️ Flux Implicite : DÉPRÉCIÉ. N'utilisez plus ce flux pour de nouvelles applications en raison de ses failles de sécurité.