OpenID Connect (OIDC) est une couche d’identités qui fonctionne par-dessus OAuth 2.0, permettant aux applications d’authentifier les utilisateurs et d’obtenir leurs informations de profil. OAuth 2.0 gère l’autorisation (ce à quoi un utilisateur peut accéder), OIDC ajoute l’authentification (qui est l’utilisateur) en utilisant des tokens d’identification standardisés.

Exemple : lorsque vous cliquez sur « Continuer avec Google » pour vous connecter à Spotify, OIDC vérifie votre identité auprès de Google. Spotify reçoit les informations de votre profil, comme votre nom et votre e‑mail. Votre mot de passe Google n’est jamais communiqué. Google émet un token d’identification contenant des revendications d’identité, comme votre ID et les informations de votre profil. Certaines revendications (comme la vérification de l’e‑mail) sont explicitement marquées comme vérifiées.

OIDC a été largement adopté pour l’authentification web et mobile moderne. Publié en 2014 par l’OpenID Foundation, il combine l’autorisation OAuth 2.0 avec la vérification de l’identité. Les principaux fournisseurs d’identité prennent en charge OIDC, ce qui le rend couramment utilisé pour l’authentification unique (SSO), l’authentification sociale et les applications grand public.

Avant OIDC, les développeurs étaient confrontés à trois défis principaux :

1. Absence d’une couche d’identités standard

   OAuth 2.0 fournit une autorisation, mais ne définit pas de méthode d’authentification standardisée ou interopérable. En conséquence, les développeurs ont créé des solutions personnalisées, ce qui a entraîné des problèmes d’interopérabilité.

2. Alternatives complexes

   SAML 2.0 prend en charge l’authentification d’entreprise, mais utilise un langage XML verbeux, exige des certificats et fonctionne mal sur les terminaux mobiles.

3. Risques d’exposition des identifiants

   Auparavant, les applications stockaient souvent les identifiants de l’utilisateur ou exigeaient le partage du mot de passe, ce qui entraînait des risques de sécurité et une expérience utilisateur médiocre.

OIDC résout ces divers problèmes. Les applications reçoivent des tokens d’identification signés cryptographiquement avec des revendications d’identité. Le stockage des identifiants n’est plus nécessaire, et l’authentification est cohérente sur toutes les plateformes. OIDC authentifie les utilisateurs, mais ne gère pas les données, les rôles ou les autorisations des utilisateurs propres à l’application.

OIDC s’appuie sur les rôles d’OAuth 2.0 et sur une terminologie propre à l’identité :

• Utilisateur final : la personne dont l’identité est vérifiée.
• Partie utilisatrice : l’application qui demande l’authentification de l’utilisateur.
• Fournisseur OpenID : le fournisseur d’identité qui authentifie les utilisateurs et émet des tokens d’identification. Dans OIDC, le fournisseur OpenID fait office de serveur d’autorisation OAuth 2.0.

Revendications des tokens d’identification

Les tokens d’identification sont des JSON Web Tokens (JWT) qui contiennent des revendications d’identité et doivent être validés avant utilisation :

• sub : identifiant unique et stable de l’utilisateur au sein de l’émetteur
• iss : émetteur du token (URL du fournisseur OpenID)
  aud : application visée (identifiant du client)
• exp : horodatage de l’expiration (horodatage Unix)
• iat : horodatage de l’émission (horodatage Unix)
• auth_time : horodatage de l’authentification
• nonce : empêche les attaques par relecture (obligatoire s’il est envoyé dans la demande)

Champs d’application communs d’OIDC

Les champs d’application définissent les informations utilisateurs demandées :

• openid : obligatoire ; déclenche OIDC
• profile : nom, photo et informations de base sur le profil
• email : adresse e‑mail et vérification
• address : adresse physique
• telephone : numéro de téléphone et vérification

Puisqu’OIDC étend OAuth 2.0, le flux est similaire au flux de code d’autorisation d’OAuth avec des ajouts spécifiques à OIDC.

Le flux d’authentification OIDC

1. Demande d’authentification : la partie utilisatrice redirige l’utilisateur vers le fournisseur OpenID avec l’ID client, l’URI de redirection, response_type=code et le champ d’application incluant openid.
2. Authentification et consentement de l’utilisateur : le fournisseur OpenID authentifie l’utilisateur à l’aide d’un mot de passe, du MFA ou de données biométriques. L’écran de consentement affiche les données demandées.
3. Réponse d’autorisation : le fournisseur OpenID renvoie un code d’autorisation et un paramètre d’état.
   Demande de token : la partie utilisatrice échange un code contre trois tokens : un token d’identification, un token d’accès et un token d’actualisation facultatif. Les clients confidentiels effectuent cette opération de serveur à serveur. Les clients publics utilisent PKCE.
4. Validation de token : la partie utilisatrice valide la signature, l’expiration, l’émetteur, l’audience et le nonce du token d’identification à l’aide des clés publiques du fournisseur (JWKS). Le token d’identification est réservé à l’application cliente et ne doit jamais être envoyé aux API. Les API doivent valider les tokens d’accès à la place.
5. Accès au profil de l’utilisateur : de façon facultative, la partie utilisatrice appelle l’endpoint UserInfo avec un token d’accès pour récupérer des informations supplémentaires sur le profil.

Proof Key for Code Exchange (PKCE)

PKCE empêche les attaques par interception du code d’autorisation. Les clients publics (applications mobiles et monopages) utilisent PKCE car ils ne peuvent pas stocker en toute sécurité les secrets clients. Les clients confidentiels s’authentifient généralement à l’aide d’un secret client. De nombreux déploiements modernes ajoutent également PKCE pour assurer une défense renforcée.

Pour déterminer le flux à utiliser :

Flux	Cas d’usage	Sécurité	État
Code d’autorisation avec PKCE	Toutes les applications modernes (web, mobiles, monopages)	La plus forte	Recommandé pour tous les clients
Flux implicite	Aucun	Faible	Obsolète (RFC 8252)
Flux hybride	Grande entreprise complexe	Moyenne	Hérité uniquement

• Le code d’autorisation avec PKCE est la bonne pratique recommandée et devrait être obligatoire dans OAuth 2.1.
• Le flux implicite est obsolète en raison de vulnérabilités de sécurité.
• Le flux hybride est principalement utilisé dans des scénarios d’entreprise hérités ou spécialisés et n’est généralement pas nécessaire pour la plupart des applications modernes.

Validation du token d’identification

Les tokens d’identification doivent être validés au niveau de la signature, de l’expiration, de l’émetteur, de l’audience et du nonce.

Étapes de validation :

• Vérifier la signature à l’aide de clés JWKS
• Vérifier que l’émetteur correspond au fournisseur
• Vérifier que l’audience correspond à l’identifiant client
• Confirmer que le token n’a pas expiré
• Vérifier que le nonce correspond à la demande

Bonne pratique : utilisez des bibliothèques OIDC établies qui gèrent la validation.

Traitement des nonces

Le nonce empêche les attaques par relecture. Un attaquant pourrait lire à nouveau un token d’identification valide sans nonce. Les nonces prévisibles, réutilisés ou non vérifiés ne sont pas sûrs.

Bonne pratique : générez des nonces cryptographiquement aléatoires, stockez-les côté serveur avec un TTL de 5 à 10 minutes et validez les correspondances exactes.

Stockage des tokens

Les tokens d’identification contiennent des informations sensibles : n’utilisez jamais localStorage ou sessionStorage en raison des vulnérabilités XSS (Cross-Site Scripting).

Bonne pratique : utilisez un stockage en mémoire pour les applications monopages ou des cookies HttpOnly sécurisés lorsque vous utilisez un modèle backend-for-frontend (BFF). Les sessions chiffrées côté serveur sont plus sûres.

Demandes de champs d’application

Ne demandez que les champs d’application dont votre application a besoin. Évitez les données de profil inutiles.

Utilisation de l’endpoint UserInfo

N’appelez UserInfo que si le token d’identification ne contient pas les revendications requises. L’endpoint nécessite un token d’accès et est souvent soumis à des limites de débit. Validez toujours les tokens d’accès et mettez les réponses en cache si nécessaire.

OIDC est idéal pour les applications grand public, les applications mobiles et l’authentification web moderne. Choisissez OIDC pour l’authentification sociale, le SSO et les scénarios où les utilisateurs s’authentifient avec des comptes existants.

SAML 2.0 reste monnaie courante dans les systèmes hérités des grandes entreprises et des organismes publics, tandis que de nombreuses entreprises adoptent de plus en plus souvent OIDC pour les nouvelles applications destinées aux collaborateurs. De nombreuses organisations utilisent les deux : OIDC pour les applications modernes et SAML pour la fédération d’entreprise.

• Validez les tokens d’identification de façon exhaustive à l’aide de clés JWKS. Vérifiez la signature, exp, iss, aud et le nonce. (Les tokens d’identification ne doivent jamais être envoyés aux API.)
• Utilisez HTTPS pour toutes les communications de production. La RFC 6749 autorise des exceptions localhost pour le développement uniquement.
• Implémentez PKCE pour tous les clients (cela devrait être obligatoire dans OAuth 2.1).
• Sécurisez le stockage des tokens avec des cookies HttpOnly ou des sessions côté serveur.
• Validez explicitement les URI de redirection. N’utilisez jamais de caractères génériques.
• Implémentez le paramètre d’état pour prévenir les attaques CSRF.
• Utilisez des tokens de courte durée (15 à 60 minutes) et des tokens d’actualisation avec rotation.
• Respectez le consentement de l’utilisateur et limitez autant que possible les données de profil demandées.

Aspect	OIDC	OAuth 2.0	SAML 2.0
Objectif	Authentification	Autorisation	Authentification et SSO
Repose sur	OAuth 2.0	Spécifications OAuth de l’IETF	Standards SAML basés sur XML
Format de token	JWT	Token au porteur (format non spécifié)	XML
Revendications d’identité	Standardisé	Non défini	Énoncés d’attributs
Support mobile	Excellent	Excellent	Médiocre
Cas d’usage	Authentification de l’utilisateur, authentification sociale	Accès aux API	Enterprise SSO
Complexité	Faible	Faible	Élevée
Profils cibles	Applications modernes	API	Fédération d’entreprise

OIDC et OAuth2.0 se complètent. OIDC répond à la question « Qui est cet utilisateur ? ». OAuth 2.0 répond à la question « À quoi cet utilisateur peut-il accéder ? ». SAML est largement utilisé pour le SSO d’entreprise. OIDC est privilégié pour les applications modernes et le support mobile.

Quelle est la différence entre OAuth 2.0 et OpenID Connect ?

OAuth 2.0 est destiné à l’autorisation. OIDC ajoute l’authentification. OAuth répond à la question « À quoi cette application peut-elle accéder ? ». OIDC répond à la question « Qui est cet utilisateur ? ».

Qu’est-ce qu’un token d’identification et pourquoi est-ce important ?

Un token d’identification est un JWT signé contenant des revendications d’identité affirmées par le fournisseur. Il prouve que l’authentification a eu lieu. Contrairement aux tokens d’accès, il est destiné au client afin de vérifier l’identité d’un utilisateur. La signature permet une validation sans contact avec le fournisseur. Les revendications courantes incluent l’identifiant de l’utilisateur (sub), l’e‑mail et l’heure d’authentification. Il faut toujours valider les tokens d’identification.

Puis-je utiliser OIDC sans OAuth 2.0 ?

Non. OIDC fonctionne par-dessus OAuth 2.0. Chaque flux OIDC est un flux OAuth 2.0 auquel ont été ajoutés le champ d’application openid et le token d’identification. OIDC étend OAuth 2.0 ; il ne le remplace pas.

OIDC est-il plus sûr que le SAML ?

Les deux sont sûrs s’ils sont implémentés correctement. OIDC utilise une validation JWT plus simple. SAML nécessite des signatures XML, qui sont de nature plus complexe. La plupart des vulnérabilités proviennent d’erreurs d’implémentation, et non du protocole lui-même. Le format plus simple des tokens d’OIDC permet de réduire les risques d’implémentation.

Qu’est-ce que l’endpoint UserInfo ?

L’endpoint UserInfo renvoie des revendications supplémentaires sur le profil de l’utilisateur. Il requiert un token d’accès valide, pas le token d’identification. Ne l’utilisez que si le token d’identification ne contient pas les revendications nécessaires. L’endpoint est souvent limité en termes de débit ; implémentez donc la mise en cache pour améliorer les performances.

Dois-je valider les tokens d’identification d’un fournisseur de confiance ?

Oui. Validez toujours la signature, l’émetteur, l’audience, l’expiration et le nonce. La validation garantit que le token est authentique, actuel et destiné à votre application. Même les tokens provenant de fournisseurs de confiance doivent être validés afin d’éviter les altérations et les attaques par relecture.

OIDC peut-il fonctionner sans HTTPS ?

Non. HTTPS est nécessaire pour la production. Les attaquants peuvent intercepter les tokens envoyés via HTTP. Les exceptions localhost ne sont autorisées qu’à des fins de développement.

Utilisation des bibliothèques OIDC

Les bibliothèques matures gèrent la validation des tokens, la gestion des clés JWKS et les détails du protocole. Les bibliothèques peuvent contribuer à réduire les erreurs, mais elles nécessitent une compréhension des concepts d’OIDC.

Les bibliothèques open source les plus répandues sont les suivantes :

• Node.js : openid-client
• Python : authlib
• Python : pyoidc
• Java : Spring Security OAuth

Utilisation des plateformes d’identité

Les plateformes d’identité proposent des implémentations OIDC et OAuth 2.0 avec des capacités intégrées de sécurité, d’authentification sociale et de traduction de protocole. Elles peuvent également gérer les mises à jour, la conformité et la montée en charge, ce qui permet aux développeurs de se concentrer sur la logique de l’application.

Auth0 simplifie les implémentations OIDC et OAuth 2.0, permettant aux développeurs de se concentrer sur la création d’applications tout en gérant de manière sécurisée l’authentification et l’identité.

Explorez notre série d’articles « Introduction à l’IAM » sur la gestion des identités et des accès.

En savoir plus

Le contenu de ce document revêt un caractère purement informatif. Il vous revient de vous adresser à des conseillers professionnels pour obtenir des conseils en matière de sécurité, confidentialité, conformité ou conduite des affaires, et de ne pas vous en remettre aux recommandations formulées dans le présent document.