Qu'est-ce qu'OpenID Connect (OIDC) ?

OpenID Connect en bref#

OpenID Connect (OIDC) est un protocole d’authentification. Il permet à une application de déléguer la connexion de ses utilisateurs à un service spécialisé, le fournisseur d’identité, puis de recevoir la preuve que l’utilisateur s’est bien authentifié, avec quelques informations sur lui : identifiant, nom, adresse e-mail.

Quand vous cliquez sur « Se connecter avec… » sur un site, puis revenez connecté sans avoir créé de mot de passe, il y a de fortes chances qu’OpenID Connect soit à l’œuvre.

OIDC n’est pas un protocole indépendant : c’est une fine couche ajoutée à OAuth 2.0. Il en reprend les redirections, les endpoints et les jetons, et y ajoute ce qui manquait pour identifier l’utilisateur.

Pourquoi OIDC existe#

OAuth 2.0 répond à une question d’autorisation : « cette application a-t-elle le droit d’accéder à cette ressource ? ». Le jeton d’accès qu’il délivre est destiné à une API, et rien dans la norme ne dit comment l’application peut savoir qui l’a obtenu.

Avant OIDC, chaque fournisseur comblait ce vide à sa façon : un endpoint propriétaire pour lire le profil, un format de réponse maison, des règles de validation différentes. Une application qui voulait accepter plusieurs fournisseurs devait écrire une intégration par fournisseur.

OpenID Connect standardise trois choses :

• un jeton d’identité (ID token) au format JWT, signé par le fournisseur, qui décrit l’authentification ;
• un endpoint UserInfo qui renvoie les informations du profil ;
• une liste de scopes et de claims communs (profile, email, address, phone…), pour que tous les fournisseurs parlent la même langue.

Les acteurs#

L’application ne voit jamais le mot de passe, le code TOTP ou la passkey de l’utilisateur : toute l’authentification se déroule chez le fournisseur. L’application reçoit seulement le résultat, sous une forme qu’elle peut vérifier.

Comment se déroule une connexion#

Le parcours recommandé est le flux Authorization Code avec PKCE. Il convient aussi bien à une application web classique qu’à une application mobile ou monopage.

Quelques paramètres méritent qu’on s’y arrête :

• scope=openid transforme une demande OAuth 2.0 en demande OpenID Connect. Sans lui, pas d’ID token.
• state est une valeur aléatoire que l’application retrouve au retour : elle prouve que la réponse correspond bien à une demande qu’elle a émise, et protège contre les attaques CSRF.
• nonce est recopié par le fournisseur dans l’ID token. L’application vérifie qu’il correspond à celui qu’elle a envoyé, ce qui empêche de rejouer un ancien jeton.
• code_challenge et code_verifier (PKCE) lient le code d’autorisation à l’application qui l’a demandé. Un code intercepté est inutilisable sans le secret qui l’accompagne.

Le jeton d’identité#

L’ID token est le cœur d’OpenID Connect. C’est un JWT signé par le fournisseur ; une fois décodé, sa partie centrale ressemble à ceci :

{
  "iss": "https://login.example.fr/tosiam/oauth2/clients",
  "sub": "b7c1e2a4-5f0d-4c3b-9a8e-2d6f1e0c7a93",
  "aud": "portail-rh",
  "iat": 1790496000,
  "exp": 1790499600,
  "auth_time": 1790495990,
  "nonce": "n-0S6_WzA2Mj",
  "acr": "mfa",
  "amr": ["pwd", "otp"],
  "email": "claire.martin@example.fr"
}

Avant de faire confiance à un ID token, l’application vérifie sa signature avec les clés publiques du fournisseur, puis iss, aud, exp et nonce. Les bibliothèques OIDC font ces contrôles pour vous ; il suffit de ne pas les désactiver.

Scopes et claims#

Les scopes indiquent ce que l’application demande ; les claims sont les informations qu’elle reçoit. OpenID Connect définit quatre scopes standard en plus de openid :

Ces claims peuvent figurer dans l’ID token, ou être lus à la demande sur l’endpoint UserInfo avec l’access token. Un fournisseur peut aussi exposer ses propres claims, par exemple un service ou un matricule.

Les endpoints d’un fournisseur#

Un fournisseur OIDC publie un document de découverte à une adresse fixe : l’adresse de l’émetteur suivie de /.well-known/openid-configuration. Ce document JSON liste tout ce qu’une application doit savoir pour s’y connecter. Dans la plupart des bibliothèques, il suffit donc de configurer l’adresse de l’émetteur, un client_id et une URL de retour.

OIDC, OAuth 2.0 et SAML#

OIDC et SAML 2.0 remplissent la même fonction : permettre l’authentification unique entre organisations et applications. SAML reste très présent dans les applications d’entreprise ; OIDC s’est imposé pour les nouvelles applications, parce que JSON et JWT sont plus simples à manipuler que XML, en particulier sur mobile.

Bonnes pratiques#

• Utilisez le flux Authorization Code avec PKCE, y compris pour les applications monopages. Les flux « implicit » et « hybrid », qui font passer des jetons par l’URL du navigateur, sont déconseillés.
• Envoyez toujours un state et un nonce, et vérifiez-les au retour.
• Vérifiez l’ID token avant de lui faire confiance, et identifiez l’utilisateur par le couple iss + sub, jamais par son adresse e-mail seule.
• Déclarez des URL de retour exactes chez le fournisseur, sans caractère générique.
• Récupérez les clés du fournisseur depuis jwks_uri plutôt que de les copier en dur : elles changent lors d’une rotation.

OpenID Connect dans TOSIAM#

TOSIAM joue les deux rôles du protocole.

TOSIAM fournisseur (OP). Le service OAuth2 Provider, activé par royaume, fait de TOSIAM un fournisseur OpenID Connect complet. L’émetteur est l’adresse /oauth2 du serveur, suivie du nom du royaume pour un sous-royaume, par exemple https://login.example.fr/tosiam/oauth2/clients. Le document de découverte y ajoute /.well-known/openid-configuration et annonce notamment :

• les endpoints d’autorisation, de jeton, UserInfo, de clés (/connect/jwk_uri), d’introspection et de fin de session (/connect/endSession) ;
• l’enregistrement dynamique des clients (/connect/register) ;
• les requêtes d’autorisation poussées (PAR, endpoint /par) ;
• la déconnexion par canal arrière (back-channel logout) et la gestion de session (check_session_iframe) ;
• la signature des ID tokens en HS256 à HS512, RS256 à RS512 et ES256 à ES512.

Chaque application est déclarée comme un agent OAuth 2.0 dans le royaume : URL de retour, scopes, grant types, méthode d’authentification. Le contenu de l’ID token et de la réponse UserInfo se règle par un script de claims, qui peut lire le profil de l’utilisateur et ajouter vos propres claims. L’authentification elle-même est celle de TOSIAM : un graphe d’authentification peut exiger une passkey, un code TOTP ou une analyse de risque avant que le jeton ne soit émis.

TOSIAM client (RP). Dans un graphe, les nœuds OidcRedirectNode et OidcCallbackNode délèguent la connexion à un autre fournisseur OpenID Connect, par exemple l’annuaire d’un partenaire ou un fournisseur social. Ils utilisent le flux Authorization Code avec PKCE, puis lisent l’ID token reçu pour retrouver ou créer le compte local.

Pour aller plus loin#

• OpenID Connect Core 1.0, la spécification de référence
• OpenID Connect Discovery 1.0, le document de découverte
• OpenID Connect Back-Channel Logout 1.0