Qu'est-ce que OIDC : Pourquoi nous en avons besoin et comment cela fonctionne

Définition d'OpenID Connect (OIDC)#

OpenID Connect (OIDC) est un protocole d'authentification des identités construit sur OAuth 2.0. Bien qu'OAuth 2.0 ne fournisse que l'autorisation, OIDC ajoute des capacités d'authentification, offrant une solution plus standardisée pour les scénarios d'autorisation et d'authentification des utilisateurs.

En termes simples : OIDC = Protocole d'autorisation + Authentification d'identité.

Pourquoi avons-nous besoin de OIDC ?#

Pour comprendre pourquoi OIDC est nécessaire, explorons d'abord les concepts de base et le flux de travail d'OAuth 2.0, ainsi que ses limitations dans les applications pratiques. En analysant des scénarios spécifiques, nous verrons pourquoi nous avons besoin de OIDC par-dessus OAuth 2.0.

Concepts clés et flux d'autorisation d'OAuth 2.0#

OAuth 2.0 (Open Authorization) est un protocole d'autorisation qui permet aux utilisateurs de donner à des applications tierces l'accès à leurs ressources sans partager leurs identifiants comme les noms d'utilisateur et les mots de passe. Il implique quatre rôles principaux :

• Propriétaire de ressource : L'utilisateur qui possède les ressources
• Serveur de ressource : Le serveur qui stocke les ressources utilisateur
• Client : L'application tierce demandant l'accès aux ressources utilisateur
• Serveur d'autorisation : Le serveur qui vérifie l'identité de l'utilisateur et délivre des jetons d'accès

Un flux d'autorisation typique d'OAuth 2.0 fonctionne ainsi :

Comme montré, OAuth 2.0 s'occupe principalement de la délivrance des jetons d'accès pour que les clients tiers accèdent aux ressources utilisateur.

La limitation d'OAuth 2.0#

Le protocole OAuth 2.0 se concentre uniquement sur la délivrance des jetons d'accès. Le serveur de ressource valide ces jetons et retourne les ressources autorisées. Cependant, le serveur de ressource ne connaît pas l'identité de l'utilisateur.

Ce n'était pas un problème significatif dans l'écosystème internet primitif.

Cependant, à mesure que des plateformes comme Google, Facebook, Twitter et Github ont évolué, elles ont commencé à offrir des ressources utilisateur riches qui sont devenues précieuses pour les applications tierces.

Alors qu'OAuth 2.0 excelle à autoriser l'accès de tiers aux ressources utilisateur, il présente des limitations. Un scénario typique est : comme l'information de l'utilisateur est également une ressource, lorsque des applications tierces ont besoin d'accéder à des informations de base sur l'utilisateur, différentes plateformes (comme Google, Facebook, Twitter) retournent les informations utilisateur dans des formats différents, créant des défis pour les développeurs.

OIDC a été créé pour remédier à ces défis.

Rôles dans OIDC#

Pour permettre l'authentification des utilisateurs en plus d'OAuth 2.0 et répondre à ses limitations, OIDC a introduit trois rôles :

• Utilisateur final (EU) : L'utilisateur final, correspondant au Propriétaire de ressource dans OAuth 2.0
• Partie de confiance (RP) : La partie dépendante, correspondant au Client dans OAuth 2.0
• Fournisseur d'identité (OP) : Le fournisseur de service d'authentification d'identité, correspondant au Serveur d'autorisation et Serveur de ressource d'OAuth 2.0

Le OP est le rôle clé, fournissant à la fois les fonctionnalités d'autorisation d'OAuth 2.0 et traitant les informations utilisateur comme une ressource distincte.

Comment fonctionne OIDC ?#

Le processus d'authentification de l'OIDC est similaire à celui d'OAuth 2.0, mais comme le OP combine les rôles de Serveur d'autorisation et Serveur de ressource, il retourne à la fois un Jeton d'accès et un ID Token. L'ID Token contient des informations d'identité de l'utilisateur, et le RP peut vérifier l'identité de l'utilisateur en validant l'ID Token.

Un flux de travail typique ressemble à ceci :

Cela standardise la façon dont l'information utilisateur est obtenue sur différentes plateformes, éliminant le besoin pour les applications tierces de gérer les différences spécifiques à chaque plateforme.

Jeton ID (token d'identité) dans OIDC#

Lorsque les utilisateurs autorisent des applications tierces, le OP retourne à la fois un Jeton d'accès OAuth 2.0 et un ID Token au format JWT. Cet ID Token contient des informations d'identité utilisateur comme l'ID utilisateur, le nom d'utilisateur, l'email, et l'avatar. Le RP peut confirmer l'identité de l'utilisateur en validant l'ID Token.

En tant que JWT, l'ID Token contient des revendications standardisées, y compris ces revendications de base requises :

• iss (Émetteur) : Identifiant unique du Fournisseur d'identité émettant l'ID Token
• sub (Sujet) : Identifiant unique de l'utilisateur
• aud (Audience) : Identifiant de l'application cliente recevant l'ID Token
• exp (Expiration) : Quand l'ID Token expire
• iat (Émis à) : Quand l'ID Token a été émis

Pour des informations détaillées sur les jetons ID, veuillez consulter : ID token.

Endpoint userinfo#

L'Endpoint Userinfo est une API HTTP standardisée fournie par le OP pour obtenir les détails de l'utilisateur authentifié. En envoyant des requêtes GET ou POST avec un Jeton d'accès à cet endpoint, vous pouvez recevoir les informations utilisateur au format JSON. Les données retournées incluent des champs standardisés comme l'ID utilisateur unique (sub), le nom d'utilisateur (name), l'email, et l'image.

Le processus d'obtention des informations utilisateur suit le même schéma que l'accès aux ressources protégées dans OAuth 2.0. Généralement, les informations utilisateur obtenues à partir de l'endpoint userinfo sont plus complètes que ce qui se trouve dans le Jeton ID, car le Jeton ID sert principalement à l'authentification d'identité et aux informations utilisateur de base.

Pour des informations détaillées sur l'endpoint userinfo, veuillez consulter : Userinfo endpoint.

Notez que les informations utilisateur que vous recevez de l'endpoint userinfo dépendent des scopes demandés et des permissions accordées lors de l'autorisation.

Scopes dans OIDC#

Les scopes dans OIDC définissent les informations utilisateur auxquelles le RP peut accéder. OIDC définit des scopes standards, le scope openid étant obligatoire dans les flux d'authentification OIDC.

Les scopes standards courants incluent :

• openid : Indique une demande d'authentification OIDC
• profile : Informations de base sur l'utilisateur comme le nom et l'avatar
• email : Informations sur l'email de l'utilisateur
• phone : Numéro de téléphone de l'utilisateur
• address : Informations sur l'adresse de l'utilisateur

Les différents scopes retournent différentes informations utilisateur. Par exemple, demander openid profile email retourne des informations utilisateur de base et l'email dans l'ID Token et l'Userinfo, tandis que openid profile email phone address inclut également le numéro de téléphone et les informations d'adresse.

La gestion des identités basée sur OIDC#

OIDC n'est pas seulement un protocole d'authentification ; c'est un outil puissant pour construire des systèmes de gestion des identités flexibles et évolutifs. En ajoutant une couche d'authentification à OAuth 2.0, en standardisant les ressources d'information utilisateur, et en jetant les bases pour des fonctionnalités étendues de gestion des identités, OIDC permet divers scénarios de gestion des identités :

• Authentification unique (SSO) : OIDC prend naturellement en charge le SSO grâce à des informations étendues sur la session utilisateur, permettant une gestion unifiée de l'état de connexion et un partage d'identité inter-applications
• Gestion de la structure organisationnelle : Les informations organisationnelles utilisateur étendues peuvent gérer des structures organisationnelles complexes, y compris des hiérarchies de départements et des relations de groupes d'utilisateurs
• Gestion des permissions : Les attributs de permission utilisateur étendus permettent un contrôle d'accès aux ressources finement granulaire, y compris les informations de rôle et la configuration des politiques de permission

La flexibilité d'OIDC s'adapte à l'évolution des besoins de gestion des identités. De nombreux systèmes de gestion des identités sont construits sur OIDC, comme Logto, qui offre des fonctionnalités de SSO, de gestion des organisations, et de gestion des permissions.