Technical Tutorials

Dans le paysage moderne du développement d'applications, la sécurité n'est pas qu'une fonctionnalité ; c'est le fondement. Pour les développeurs créant des systèmes distribués complexes, la gestion manuelle de l'identité et du contrôle d'accès est souvent source de problèmes. C'est là qu'interviennent OAuth 2.0 et OpenID Connect (OIDC). Bien qu'ils soient souvent utilisés ensemble, ces deux protocoles ont des objectifs distincts. Les confondre peut entraîner des vulnérabilités de sécurité critiques, allant de l'accès non autorisé aux données au piratage de session.

Cet article vise à clarifier les différences, à expliquer leur fonctionnement interne et à fournir des conseils pratiques pour les implémenter de manière sécurisée dans vos applications.

Comprendre la distinction : Autorisation vs Authentification

Pour maîtriser ces protocoles, vous devez d'abord comprendre le problème que chacun résout. Imaginez un club avec une zone VIP et un système d'adhésion.

OAuth 2.0 est un cadre d'autorisation. Il fournit une méthode pour un accès restreint aux ressources hébergées. Dans notre analogie, OAuth est le bracelet que vous obtenez après avoir prouvé votre identité à l'entrée, ce qui vous permet d'entrer dans le salon VIP et de boire au bar premium. Il répond à la question : « Que cette application est-elle autorisée à faire pour le compte de l'utilisateur ? »

OpenID Connect (OIDC) est une couche d'authentification au-dessus d'OAuth 2.0. Il fournit des informations d'identité. Dans notre analogie, OIDC est la carte d'identité vérifiée par l'agent de sécurité pour s'assurer que la personne qui entre est bien celle qu'elle prétend être. Il répond à la question : « Qui est cet utilisateur ? »

Utiliser uniquement OAuth 2.0 pour la connexion est une mauvaise pratique courante. Bien qu'il vous permette d'identifier un utilisateur par son ID utilisateur, il ne garantit pas l'intégrité de cette identité sans les revendications supplémentaires fournies par OIDC.

Fonctionnement d'OpenID Connect

OIDC étend OAuth 2.0 en ajoutant un id_token, qui est un jeton web JSON (JWT) signé par le fournisseur d'identité (IdP). Ce jeton contient des revendications concernant l'événement d'authentification, telles que l'identifiant du sujet, l'émetteur, l'audience et l'heure d'expiration.

Le flux le plus courant pour les applications monopages (SPA) et les applications mobiles est le flux de code d'autorisation avec PKCE (Proof Key for Code Exchange). Le PKCE est essentiel pour les clients publics afin de prévenir les attaques par interception de code d'autorisation.

Voici une représentation simplifiée des paramètres de demande d'autorisation OAuth 2.0 :

GET https://auth.example.com/authorize
  ?response_type=code
  &client_id=your_client_id
  &redirect_uri=https://your-app.com/callback
  &scope=openid profile email
  &state=random_state_string
  &code_challenge=e7b4...
  &code_challenge_method=S256

Remarquez le paramètre scope=openid. C'est le signal envoyé à l'IdP indiquant que vous initiez un flux OIDC, et non une simple demande d'autorisation OAuth2 standard. La réponse contiendra à la fois un jeton d'accès (pour l'accès à l'API) et un jeton d'identité (pour l'identité).

Bonnes pratiques de sécurité

Implémenter correctement ces protocoles nécessite un strict respect des normes de sécurité. Voici trois pratiques non négociables :

Toujours valider le jeton d'identité : Ne faites pas aveuglément confiance au jeton. Vérifiez la signature à l'aide des clés publiques de l'IdP (obtenues via le point de terminaison /.well-known/openid-configuration). Vérifiez que les revendications iss (émetteur) et aud (audience) correspondent à vos attentes.
Utiliser HTTPS partout : Les codes d'autorisation et les jetons ne doivent jamais être transmis sur des canaux non chiffrés. Il s'agit d'une exigence de base, et non d'une option.
Implémenter un stockage de jetons approprié : Pour les SPA, stockez les jetons en mémoire plutôt que dans localStorage ou sessionStorage, qui sont accessibles aux attaques XSS. Pour les applications côté serveur, utilisez des cookies HTTP-only et Secure.

Conclusion

OAuth 2.0 et OpenID Connect sont des outils puissants qui, lorsqu'ils sont compris et implémentés correctement, permettent aux développeurs de créer des solutions d'identité sécurisées et évolutives sans réinventer la roue. En traitant OAuth comme un protocole d'autorisation et OIDC comme un protocole d'authentification, vous vous assurez que vos applications maintiennent l'intégrité des identités des utilisateurs tout en accordant un accès approprié aux ressources. À mesure que le web continue d'évoluer, la maîtrise de ces normes reste une compétence critique pour tout développeur d'applications sérieux.