OpenID Connect (OIDC)

general

Définition

OpenID Connect (OIDC) est une couche d'identité construite au-dessus d'OAuth 2.0, standardisée par l'OpenID Foundation en 2014. Elle ajoute à OAuth 2.0 (qui ne gère que l'autorisation) la capacité d'authentification : OIDC permet à une application de vérifier l'identité d'un utilisateur à travers un fournisseur d'identité (IdP) et d'obtenir des informations de profil de base. La différence fondamentale avec OAuth 2.0 est le token ID (ID Token) : un JWT signé émis par le serveur d'autorisation qui contient les claims d'identité de l'utilisateur (sub, name, email, nonce, aud, iss, iat, exp). L'application valide ce JWT (signature, expiration, audience) pour confirmer l'authentification et obtenir l'identité de l'utilisateur, sans appel supplémentaire. OIDC standardise les endpoints de découverte (/.well-known/openid-configuration) qui exposent la configuration du provider (endpoints d'autorisation/token/userinfo, algorithmes supportés, scopes disponibles, clés publiques JWKS), permettant une intégration automatique sans configuration manuelle. Les scopes OIDC standardisés incluent : openid (obligatoire, indique qu'on veut un ID Token), profile (prénom, nom, photo), email (adresse email, email_verified), address (adresse postale), phone (numéro de téléphone), offline_access (obtenir un refresh token). Des scopes additionnels peuvent être définis par le provider pour ses attributs spécifiques. OIDC est devenu le standard dominant pour l'authentification fédérée dans les applications modernes, remplaçant progressivement SAML pour les nouvelles intégrations. "Se connecter avec Google", "Sign in with Apple", "Login with GitHub", et tous les boutons de connexion sociale utilisent OIDC. Les fournisseurs d'identité enterprise (Azure AD, Okta, Keycloak, Auth0) supportent OIDC nativement. Les patterns d'utilisation avancés incluent : OIDC Back-channel Logout pour la déconnexion globale SSO, OIDC Session Management pour détecter les déconnexions, CIBA (Client-Initiated Backchannel Authentication) pour l'authentification sur un device secondaire, et OIDC Federation pour les écosystèmes multi-IdP interopérables.

ID Token — structure JWT et validation

L'ID Token OIDC est un JWT avec un header (algorithme de signature, identifiant de clé kid), un payload (claims d'identité et de session), et une signature. Claims obligatoires : iss (émetteur, URL de l'IdP), sub (identifiant unique et stable de l'utilisateur chez cet IdP), aud (audience — client_id de l'application), exp (expiration Unix timestamp), iat (émission Unix timestamp). Claims recommandés : nonce (anti-replay, valeur aléatoire incluse dans l'autorisation et vérifiée dans l'ID Token), auth_time (timestamp de l'authentification effective). La validation côté client doit vérifier tous ces claims — une validation incomplète est une source fréquente de vulnérabilités. Les bibliothèques OIDC certifiées (openid-client en Node.js, AppAuth) gèrent cette validation automatiquement.

OIDC Discovery et JWKS — intégration automatisée

L'endpoint de découverte OIDC (/.well-known/openid-configuration) retourne un document JSON décrivant la configuration complète du provider : authorization_endpoint, token_endpoint, userinfo_endpoint, jwks_uri (endpoint des clés publiques), response_types_supported, scopes_supported, claims_supported, token_endpoint_auth_methods_supported, etc. Les JWKS (JSON Web Key Set) exposés via jwks_uri contiennent les clés publiques (RSA ou EC) utilisées pour signer les ID Tokens. Les clients OIDC téléchargent ces clés (avec cache) pour valider les tokens localement sans appel réseau à chaque requête. La rotation des clés (key rollover) doit respecter un délai pour que les clients puissent mettre à jour leur cache JWKS.

OIDC et Social Login — intégrations Google, Apple, GitHub

Les boutons "Se connecter avec Google/Apple/GitHub" sont des implémentations OIDC. Ils permettent aux utilisateurs d'utiliser leurs comptes existants sans créer un nouveau compte. Avantages : authentification forte déléguée (les IdPs majeurs imposent le MFA), pas de mot de passe à gérer pour l'application, informations de profil pré-remplies. Risques : dépendance à l'IdP (si Google suspend le compte ou modifie ses conditions, l'accès à l'application peut être perdu), problèmes de vie privée (l'IdP peut suivre les connexions), et "sign in with different provider = different account" si le sub claim change. Les applications critiques devraient permettre plusieurs méthodes de connexion et/ou un mécanisme de récupération indépendant des IdPs sociaux.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis