Revendications OpenID Connect et jetons d’ID

OpenID Connect (OIDC) ajoute une couche d'identité par-dessus OAuth 2.0. Alors qu'OAuth 2.0 gère l'autorisation (à quelles ressources cette application peut-elle accéder ?), OIDC répond à la question de l'identité (qui est l'utilisateur ?). OIDC est implémenté en ajoutant la portée "openid" à une requête OAuth 2.0, ce qui amène le serveur d'autorisation à renvoyer un jeton d'identité en plus du jeton d'accès.

Le jeton d'identité OIDC est un JSON Web Token (JWT) contenant des revendications sur l'utilisateur authentifié. Le JWT est signé par le serveur d'autorisation à l'aide de sa clé privée (généralement RS256 ou ES256), et la partie utilisatrice (l'application cliente) vérifie la signature à l'aide des clés publiques publiées par le serveur d'autorisation (point de terminaison JWKS).

Revendications du jeton d'identité obligatoires et couramment utilisées : "sub" (sujet, identifiant unique de l'utilisateur), "iss" (émetteur, URL du serveur d'autorisation), "aud" (audience, identifiant du client), "exp" (horodatage Unix d'expiration), "iat" (horodatage Unix d'émission). Facultatives : "auth_time" (moment de l'authentification), "nonce" (prévention de la relecture), "at_hash" (hachage du jeton d'accès), "acr" (classe du contexte d'authentification), "amr" (méthodes d'authentification utilisées).

Le point de terminaison UserInfo d'OIDC renvoie des revendications supplémentaires sur l'utilisateur authentifié lorsqu'il est appelé avec un jeton d'accès valide. Les clients demandent des ensembles de revendications spécifiques au moyen de portées : "profile" (nom, photo, paramètres régionaux), "email" (adresse e-mail, adresse e-mail vérifiée), "address" (adresse mise en forme), "phone" (numéro de téléphone, numéro de téléphone vérifié). La réponse UserInfo est un objet JSON ou un JWT.

La validation du jeton d'identité commence par la vérification de la signature. Le client récupère le JWKS du serveur d'autorisation (ensemble de clés Web JSON) depuis le point de terminaison bien connu, trouve la clé correspondant au paramètre "kid" (identifiant de clé) de l'en-tête du JWT, puis vérifie la signature du JWT. Cela prouve que le jeton a été émis par le serveur d'autorisation légitime et qu'il n'a pas été altéré.

Après la vérification de la signature, le client doit valider les éléments suivants : "iss" doit correspondre exactement à l'URL attendue du serveur d'autorisation (y compris le schéma et le chemin). "aud" doit contenir le client_id du client lui-même. "exp" doit être dans le futur (les jetons expirés doivent être rejetés). "iat" doit être suffisamment récent. Ces quatre vérifications sont obligatoires selon la spécification OIDC.

La revendication nonce empêche les attaques par relecture de jetons d'identité. Le client génère un nonce aléatoire et l'inclut dans la requête d'autorisation. Le serveur d'autorisation intègre le nonce au jeton d'identité. Le client vérifie que le nonce du jeton d'identité correspond à celui qu'il a envoyé. Cela empêche un attaquant qui capture un jeton d'identité de le réutiliser pour s'authentifier dans une autre session.

Lorsque OIDC utilise le flux implicite (response_type=id_token), le jeton d'identité est renvoyé directement dans le fragment de l'URL. Le client doit valider at_hash (le hachage du jeton d'accès) afin de lier le jeton d'accès au jeton d'identité. Sans validation de at_hash, des attaques par substitution du jeton d'accès sont possibles. C'est une raison supplémentaire pour laquelle le flux implicite est obsolète.

OIDC définit des correspondances standard entre les portées et les revendications. La portée "openid" est obligatoire et renvoie la revendication "sub". "profile" renvoie name, given_name, family_name, nickname, picture, website, locale, zoneinfo et updated_at. "email" renvoie email et email_verified. Demander des portées inutiles va à l'encontre du principe de divulgation minimale et peut exposer des données sensibles sur l'utilisateur.

Lors de l'implémentation d'une connexion OIDC auprès de plusieurs fournisseurs (par exemple, "Se connecter avec Google" et "Se connecter avec GitHub"), des attaques par injection de revendications sont possibles. Si un attaquant crée un compte chez le fournisseur B avec l'adresse e-mail d'une victime qui utilise le fournisseur A, il peut obtenir un accès si l'application associe les comptes uniquement à partir de la revendication d'adresse e-mail. Associez toujours les comptes à l'aide de la paire (iss, sub), et non de l'adresse e-mail seule.

Le flux hybride OIDC (response_type=code id_token) renvoie à la fois un code d'autorisation et un jeton d'identité depuis le point de terminaison d'autorisation. Le jeton d'identité permet de vérifier immédiatement l'identité, tandis que le code est échangé contre des jetons via le canal secondaire. Ce flux est utilisé lorsque le client doit afficher immédiatement les informations de l'utilisateur avant de terminer l'échange de jetons via le canal secondaire.

Quelle combinaison de revendications une partie utilisatrice doit-elle valider dans un jeton d'identité OIDC ?

OIDC ajoute un jeton d'identité JWT signé aux flux OAuth 2.0. Validez la signature (JWKS), iss (correspondance exacte), aud (client_id), exp (non expiré) et nonce (s'il a été envoyé). Le point de terminaison UserInfo fournit des revendications supplémentaires via les portées. Associez les comptes à l'aide de la paire (iss, sub), jamais de l'adresse e-mail seule, afin d'empêcher l'injection de revendications. Le flux implicite est obsolète ; utilisez le code d'autorisation avec PKCE pour OIDC.