OpenID Connect ou OIDC est un protocole d'identité qui utilise les mécanismes d'autorisation et d'authentification d’OAuth 2.0. La spécification finale d'OIDC a été publiée le 26 février 2014. Elle est maintenant largement adoptée par de nombreux fournisseurs d'identifiants sur Internet.

OIDC a été développé par l’OpenID Foundation, qui comprend des sociétés comme Google et Microsoft. Alors qu’OAuth 2.0 est un protocole d'autorisation, OIDC est un protocole d'authentification d'identité qui sert à vérifier l'identité d'un utilisateur d'un service client, également appelé Partie de confiance. En outre, les déclarations des utilisateurs, par exemple le nom, l'adresse électronique, etc., peuvent être partagées sur demande.

Une grande variété de clients peut utiliser OpenID Connect (OIDC) pour identifier les utilisateurs, des applications monopages aux applications natives et mobiles. Il peut également être utilisé pour l'authentification unique (SSO) entre les applications. OIDC utilise des jetons Web JSON (JWT), des flux HTTP et évite de partager les informations d'identification de l'utilisateur avec les services.

OpenID Connect intègre le consentement. Ce point est important car OIDC est souvent utilisé dans les services destinés aux consommateurs (par exemple, une partie de confiance), où le partage de données personnelles nécessite le consentement explicite de l'utilisateur.

Ces caractéristiques, ainsi que la simplicité de mise en œuvre, font d'OpenID Connect un protocole utile lorsque l'identité d'un utilisateur est requise et une alternative intéressante à SAML 2.0, plus complexe. Il convient aussi particulièrement bien aux applications mobiles.

OIDC utilise OAuth 2.0 comme protocole sous-jacent. Les principales extensions sont une valeur de portée spéciale (« openid »), un jeton supplémentaire (le jeton d'identification, qui encapsule les revendications d'identité au format JSON) et l'accent mis sur l'authentification plutôt que sur l'autorisation. De plus, dans OIDC, le terme « flux » est utilisé à la place d’« attribution » dans OAuth2.

Le fournisseur OIDC (généralement appelé fournisseur OpenID ou fournisseur d'identité ou IdP) procède à l'authentification de l'utilisateur, à son consentement et à l'émission de jetons. Le client ou le service qui demande l'identité d'un utilisateur est généralement appelé Partie de confiance (RP). Il peut s'agir, par exemple, d'une application Web, mais aussi d'une application JavaScript ou d'une application mobile.

S'appuyant sur OAuth 2.0, OpenID Connect utilise des jetons pour fournir une couche d'identité simple et intégrée au cadre d'autorisation sous-jacent. Cette intégration implique l'utilisation des types de jetons suivants :

Jeton d'identification : Spécifique à l'OIDC, ce jeton au format JWT sert principalement à fournir des informations sur le résultat de l'opération d'authentification. Sur demande, il peut aussi fournir les données d'identité décrivant un profil utilisateur. Les données sur le résultat de l'authentification et les informations sur le profil utilisateur sont appelées revendications. Les revendications du profil utilisateur peuvent être n'importe quelles données pertinentes pour la partie de confiance à des fins d'identification, telles qu'un identifiant persistant, une adresse électronique, un nom, etc.

Jeton d'accès : Défini dans OAuth2, ce jeton (facultatif) à courte durée de vie permet d'accéder à des ressources utilisateur spécifiques, telles que définies dans les valeurs de portée de la demande adressée au serveur d'autorisation.

Jeton d'actualisation : Issu des spécifications OAuth2, ce jeton a généralement une longue durée de vie. Il peut être utilisé pour obtenir de nouveaux jetons d'accès.

Les jetons d'identification doivent être signés numériquement pour éviter toute falsification. Ils peuvent être chiffrés pour assurer une confidentialité supplémentaire, bien que, dans de nombreux cas, la sécurité de la couche de transport (HTTPS) soit suffisante. Pour les applications monopages et les applications mobiles, le chiffrement des jetons d'identification n'est pas utile, car la clé de déchiffrement peut être facilement déterminée.

Le choix du flux OpenID Connect dépend du type d'application et de ses exigences en matière de sécurité. Il existe trois flux courants :

• Flux implicite : Dans ce flux, couramment utilisé par les applications monopages, les jetons sont renvoyés directement à la RP dans un URI de redirection.
• Flux de code d'autorisation : Ce flux est plus sûr que le flux implicite, car les jetons ne sont pas renvoyés directement. Pour les applications natives/mobiles et les applications monopages, la sécurité peut être renforcée en utilisant la Clé de preuve pour l'échange de codes.
• Flux hybride : Lorsqu’un flux Implicite et un flux à code d'autorisation sont combinés, le jeton d'identification est renvoyé directement à la RP, mais pas le jeton d'accès. Au lieu de cela, un code d'autorisation est renvoyé et échangé contre un jeton d'accès.

Le fournisseur OpenID détermine les méthodes d'authentification disponibles pour authentifier les utilisateurs lorsque ceux-ci se connectent à leur compte IdP et consentent éventuellement à valider leurs données d'identité auprès de la RP. Les spécifications d'OIDC ne donnent aucune information sur les mécanismes d'authentification des utilisateurs. L'IdP peut proposer un ou plusieurs facteurs, par exemple :

• Nom d'utilisateur/mot de passe
• Code à usage unique délivré hors bande, par exemple par SMS ou e-mail
• Code généré par une application (OATH, TOTP ou HOTP)
• Données biométriques via l'Application
• Fédéré (par exemple, Facebook, GoogleID)

La RP peut également avoir son mot à dire sur l'authentification IdP. Par exemple, l'authentification multi-facteur peut être demandée. Cependant, la manière dont un IdP authentifie les utilisateurs n'entre pas dans le champ d'application d'OIDC.

Poursuivez la lecture de notre page Introduction à l'IAM pour explorer d'autres sujets relatifs à la gestion des identités et des accès.