Logo Logo
GitHub Designed by Logto
oauth 2.0oidc
Modifier sur GitHub

OpenID Connect (OIDC)

OpenID Connect (OIDC) est une couche d'authentification (identity) au-dessus d'OAuth 2.0, permettant aux clients d'authentifier les utilisateurs et d'obtenir des informations d'identité de manière standardisée.

Qu’est-ce que OpenID Connect (OIDC) ?

OpenID Connect (OIDC) ajoute des capacités d’authentification au OAuth 2.0 , un cadre d’autorisation, en introduisant une couche d’identité au-dessus de celui-ci. OIDC permet aux clients d’authentifier les utilisateurs et d’obtenir des informations d’identité sous forme de ID tokens et de réponses du Point de terminaison userinfo (Userinfo endpoint) .

Prenons un exemple. Supposons que vous avez une application web appelée MyApp et que les utilisateurs peuvent se connecter en utilisant un nom d’utilisateur et un mot de passe ; après s’être connectés, ils peuvent accéder à leurs informations de profil. Voici un flux simplifié :

Certains termes peuvent être nouveaux pour vous, clarifions-les :

OpenID Provider (OP)

Un OpenID Provider (OP) est un Fournisseur d'identité (Identity provider, IdP) qui implémente les spécifications OIDC et OAuth 2.0. Autrement dit, un OP est également un Serveur d'autorisation (Authorization server) OAuth 2.0.

Les OPs sont responsables de l’authentification des utilisateurs et de l’émission d’ID tokens et d’access tokens aux clients.

Tokens

  • Les ID tokens sont des JSON Web Tokens utilisés pour représenter des informations d’identité de l’utilisateur, telles que le nom, l’email et la photo de profil.
  • Les Access tokens sont utilisés pour accéder à des ressources protégées au nom de l’utilisateur (comme dans OAuth 2.0), par exemple le userinfo endpoint.

Authentication request et résultat

  • Un Requête d'authentification (Authentication request) est une demande faite par le client à l’OP pour authentifier l’utilisateur. Elle inclut des paramètres pour spécifier certaines exigences et influencera le processus d’authentification.
  • Selon l’authentication request, le résultat d’authentification peut varier. Pour l’instant, sachez simplement que le résultat contient les informations nécessaires pour que le client identifie l’utilisateur.

Userinfo endpoint

Le Point de terminaison userinfo (Userinfo endpoint) est un endpoint spécifique à OIDC qui permet aux clients de récupérer des informations de profil utilisateur. C’est une alternative à l’utilisation des ID tokens puisque le userinfo endpoint fournit généralement plus d’informations détaillées sur l’utilisateur que l’ID token.

OIDC laisse l’OpenID Provider (OP) décider quelles informations inclure dans l’ID token et la réponse du userinfo. Ainsi, avant d’analyser l’ID token ou d’appeler le userinfo endpoint, vous devez consulter la documentation de l’OP pour comprendre quelles informations sont disponibles.

Différences de termes entre OAuth 2.0 et OIDC

Étant donné qu’OIDC est construit sur OAuth 2.0, de nombreux termes sont partagés entre les deux spécifications. Cependant, alors qu’OAuth 2.0 se concentre sur l’autorisation, OIDC introduit l’authentification et l’identité, rendant certains termes inappropriés dans le contexte d’OIDC. Voici quelques différences notables :

OAuth 2.0OpenID Connect (OIDC)
Authorization serverOpenID Provider (OP)
Authorization requestAuthentication request
GrantFlow

En substance, les termes ci-dessus peuvent désigner le même sujet, mais ils ont des significations différentes dans le contexte d’OAuth 2.0 et d’OIDC :

Flows OIDC

Comme le montre l’exemple ci-dessus, les flows OIDC sont initiés par le client (par exemple, MyApp) avec un authentication request à l’OP. L’authentication request spécifie le flux à utiliser, qui peut être l’un des suivants :

L’authorization code flow et l’implicit flow sont étendus d’OAuth 2.0 pour inclure des ID tokens, tandis que le hybrid flow est un flux spécifique à OIDC qui combine les deux. Cliquez sur les liens ci-dessus pour en savoir plus sur chaque flux.

Scopes OIDC et claims

Comme OAuth 2.0, OIDC utilise des valeurs de Portée (Scope) pour spécifier les autorisations que le client demande. Étant donné que les ID tokens sont des JSON Web Tokens , ils peuvent inclure des claims (paires clé-valeur) qui représentent les informations d’identité de l’utilisateur selon les scopes demandés dans le Requête d'authentification (Authentication request) . Ces claims sont également renvoyées dans la réponse du Point de terminaison userinfo (Userinfo endpoint) .

OIDC définit plusieurs scopes standard et claims correspondants que les clients peuvent demander dans l’authentication request :

  • openid : Indique que le client est un client OIDC et demande un ID token.
  • profile : Demande l’accès aux claims de profil par défaut de l’utilisateur, qui sont : name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, et updated_at.
  • email : Demande l’accès aux claims email et email_verified de l’utilisateur.
  • address : Demande l’accès au claim address de l’utilisateur.
  • phone : Demande l’accès aux claims phone_number et phone_number_verified de l’utilisateur.
  • offline_access : Demande un refresh token pour permettre au client d’obtenir de nouveaux access tokens sans interaction utilisateur.

Consultez Standard Claims et Requesting Claims using Scope Values dans la spécification OIDC pour plus d’informations sur les scopes et les claims. Consultez également Accès hors ligne (Offline access) pour une explication détaillée du scope offline_access.

[!Note] Les OpenID Providers (OPs) peuvent prendre en charge des scopes et des claims supplémentaires au-delà des standards. Consultez la documentation de l’OP pour plus de détails.

Autorisation dans OIDC

Si vous êtes familier avec OAuth 2.0, vous avez peut-être remarqué que l’exemple ci-dessus n’implique aucun processus d’ Autorisation (Authorization) . L’exemple a omis la partie consentement de l’utilisateur parce que nous avons supposé que MyApp est une application de première partie qui n’implique pas d’accès tiers aux données utilisateur. L’autorisation est toujours appliquée par l’OP, mais elle n’est pas explicitement montrée dans le flux.

La partie consentement de l’utilisateur est requise lorsqu’un client tiers (par exemple, une application qui n’est pas détenue par l’OP) demande un accès aux données utilisateur. Dans de tels cas, l’OP demandera à l’utilisateur de consentir à donner l’autorisation au client avant d’émettre l’ID token ou l’access token. Disons qu’une application tierce appelée ThirdApp souhaite accéder aux données utilisateur :

Une fois le processus d’autorisation terminé et que ThirdApp reçoit le résultat d’autorisation (généralement un Jeton d'accès (Access token) ), elle peut accéder aux données de l’utilisateur depuis le Serveur de ressources (Resource server) .

Voir OAuth 2.0 pour plus d’informations sur OAuth 2.0 et les flows d’autorisation.

Scopes

Semblable à OAuth 2.0, OIDC utilise des valeurs de Portée (Scope) pour spécifier les autorisations que le client demande. Nous avons couvert les scopes et claims standards dans OIDC scopes et claims . Il est important de noter que ces scopes et claims doivent être traités comme des valeurs réservées dans OIDC, ce qui signifie que vous NE devez PAS les utiliser à des fins spécifiques à l’entreprise.

En pratique, votre OpenID Provider (OP) peut prendre en charge des scopes et des claims personnalisés pour vos besoins commerciaux. Consultez la documentation de l’OP pour plus d’informations sur les scopes et claims personnalisés. Si vous ne définissez pas de scopes et claims personnalisés, l’OP peut les ignorer directement ou renvoyer une réponse d’erreur.

Indicateurs de ressources

Étant donné que le cadre comme OIDC et l’OP peuvent réserver certains scopes et claims pour des usages spécifiques, l’OP recommande généralement d’utiliser un préfixe ou un espace de noms pour éviter les conflits avec les valeurs réservées lors de la définition de scopes et claims personnalisés. Par exemple, vous pouvez préfixer vos scopes personnalisés avec myapp: pour indiquer qu’ils sont spécifiques à votre application.

{
  "scope": "myapp:custom_scope"
}

Cependant, ceci ne peut garantir que vos scopes et claims personnalisés ne seront pas en conflit avec de futures valeurs réservées, et cela peut gonfler la taille du token. Une extension OAuth 2.0 appelée indicateurs de ressources fournit un moyen plus flexible et évolutif pour atteindre le même objectif. Les indicateurs de ressources sont des URIs qui représentent les ressources demandées, et elles peuvent être les API endpoints réels pour refléter les ressources du monde réel. Par exemple, vous pouvez utiliser https://api.myapp.com comme indicateur de ressource pour représenter les ressources API que votre client souhaite accéder.

Encore une fois, étant donné qu’OIDC est construit au-dessus d’OAuth 2.0, vous pouvez utiliser des indicateurs de ressources dans les authentication requests OIDC lorsqu’ils sont correctement configurés. Voici un exemple non normatif d’une authentication request avec un indicateur de ressource :

GET /authorize?response_type=code
  &client_id=YOUR_CLIENT_ID
  &redirect_uri=https%3A%2F%2Fclient.example.com%2Fcallback
  &scope=openid%20profile
  &resource=https%3A%2F%2Fapi.example.com HTTP/1.1
Host: your-openid-provider.com

Pour utiliser des indicateurs de ressources, vous devez d’abord confirmer que votre OP supporte cette extension (RFC 8707). Si prise en charge, vous devriez enregistrer un URI d’indicateur de ressource auprès de l’OP et l’utiliser dans le paramètre resource de l’authentication request.

Consultez Indicateur de ressource (Resource indicator) pour des informations détaillées sur les indicateurs de ressources.

Considérations de sécurité OIDC

Communication sécurisée

Toutes les communications entre le client, l’OP, et le resource server doivent être sécurisées en utilisant HTTPS pour empêcher toute interception ou altération des données.

Choisir des flows sécurisés

Lors de l’implémentation d’OIDC, il est recommandé d’utiliser :

L’implicit flow et le hybrid flow sont dépréciés en raison de problèmes de sécurité, donc évitez de les utiliser pour de nouvelles applications et envisagez de migrer les applications existantes vers des flows plus sécurisés.

Validation de l’ID token

Lors de la réception d’un ID token de l’OP, le client doit valider le token pour assurer son intégrité et son authenticité. Le processus de validation devrait AU MOINS inclure les vérifications suivantes :

  • Issuer : Le claim iss doit correspondre à l’URL de l’issuer de l’OP.
  • Audience : Le claim aud doit correspondre au client ID du client.
  • Expiration : Le claim exp doit être dans le futur.
  • Signature : Le token doit être signé par la Clé de signature (Signing key) de l’OP.

Utilisation des access tokens

Les access tokens sont utilisés pour accéder aux ressources protégées au nom de l’utilisateur. Les clients doivent traiter les access tokens comme des informations sensibles et suivre ces meilleures pratiques :

  • Stockage des tokens : Stockez les access tokens de manière sécurisée et évitez de les exposer à des parties non autorisées.
  • Expiration des tokens : Les access tokens doivent avoir un temps d’expiration court (par exemple, 1 heure) pour réduire le risque d’accès non autorisé si le token est compromis.
  • Révocation des tokens : Implémentez des mécanismes de révocation de tokens pour invalider les access tokens si nécessaire.

Consentement de l’utilisateur

Lorsqu’un client tiers demande l’accès aux données utilisateur, l’OP doit s’assurer que l’utilisateur est conscient des autorisations demandées et accorde son consentement. Le processus de consentement de l’utilisateur doit être transparent et fournir des informations claires sur les données auxquelles on accède et comment elles seront utilisées.

Voir aussi