OpenID Connect

OpenID Connect, l’essentiel

OAuth 2.0 donne l’accès à une ressource. OpenID Connect y ajoute l’identité : qui est la personne qui se connecte.

OAuth 2.0 et OpenID Connect : la différence

OAuth 2.0 répond à « cette application a-t-elle le droit d’accéder à ces données ? » Il produit un jeton d’accès. Il ne dit rien de la personne.

OpenID Connect (OIDC) est une couche d’identité au-dessus d’OAuth 2.0. Il ajoute un jeton d’identité (ID token), un point d’accès userinfo et des scopes standard (openid, profile, email). Si vous demandez le scope openid, vous faites de l’OIDC ; sinon, de l’OAuth pur.

Les acteurs

• Utilisateur (resource owner) : la personne.
• Client (RP, relying party) : l’application qui veut connaître la personne ou accéder à une API.
• Fournisseur OIDC (OP, authorization server) : Entra ID, Okta, Keycloak, Google… il authentifie et émet les jetons.
• API (resource server) : reçoit le jeton d’accès et le valide.

Les trois jetons

• ID token : un JWT signé qui dit qui s’est connecté (sub), par qui (iss), pour qui (aud = votre client_id), quand (iat, exp) et rejoue votre nonce. Il est destiné à l’application, jamais à l’API.
• Access token : la clé que l’application présente à une API. Opaque ou JWT, courte durée. L’application ne doit pas le lire.
• Refresh token : permet d’obtenir un nouvel access token sans redemander la personne. Longue durée, à protéger comme un mot de passe.

Les points d’accès

/.well-known/openid-configuration	La découverte : un JSON qui liste tous les autres points d’accès et les capacités du fournisseur. Un client sérieux n’a besoin que de l’adresse de l’issuer.
jwks_uri	Les clés publiques qui servent à vérifier la signature des jetons (rotation possible).
authorization_endpoint	Là où le navigateur envoie la personne s’authentifier.
token_endpoint	Là où l’application échange un code (ou autre) contre des jetons, de serveur à serveur.
userinfo_endpoint	Les informations de la personne, avec un access token.
introspection, revocation	Vérifier si un jeton est encore actif (RFC 7662) ; l’invalider (RFC 7009).
end_session_endpoint	Déconnexion demandée par l’application (RP-initiated logout).
device_authorization_endpoint	Démarrer un flow « appareil » (RFC 8628).

Les vérifications d’un client sérieux

Sur un ID token : signature (clés du jwks_uri), iss exact, aud contient son client_id, exp non dépassé, nonce identique à celui envoyé, at_hash/c_hash quand ils sont présents. Sur la réponse : state identique, et PKCE (code_verifier) avec le flow code.