OpenID Connect (OIDC)

Qu'est-ce que l'OpenID Connect (OIDC) ?

L'OpenID Connect (OIDC) est un protocole d'authentification ouvert qui fonctionne sur le cadre OAuth 2.0. Destiné aux consommateurs, l’OIDC permet aux particuliers d’utiliser la connexion unique ou SSO pour accéder à des applications (parties utilisatrices ou RP) à l’aide de fournisseurs OpenID (OP), tels qu’un fournisseur de messagerie ou un réseau social, pour authentifier leur identité. Il fournit à l'application ou au service des informations sur l'utilisateur, le contexte de son authentification et l'accès à ses informations de profil.

L’objectif de l'OIDC est de permettre aux utilisateurs de fournir un ensemble d’identifiants pour accéder à plusieurs sites. Chaque fois que les utilisateurs se connectent à une application ou à un service utilisant l'OIDC, ils sont redirigés vers leur OP, où ils s'authentifient, puis sont redirigés vers l'application ou le service.

L'OIDC a été conçu pour protéger les applications basées sur navigateur, les API et les applications mobiles natives. Il délègue l'authentification des utilisateurs au fournisseur de services qui héberge le compte utilisateur et autorise les applications tierces à accéder aux informations de l'utilisateur.

Exemple OIDC

Par exemple, il existe actuellement deux manières de créer un compte Spotify. Vous pouvez vous inscrire sur Spotify ou vous connecter via Facebook ou Google. Ces OP envoient ensuite un jeton d'identification contenant vos informations, telles que votre nom et votre adresse e-mail, à Spotify, qui utilise le jeton pour valider votre identité.

Quels sont les avantages de l'OIDC ?

Il n'est plus nécessaire de gérer les mots de passe

L'OIDC permet aux organisations de fournir une expérience d'authentification unique (SSO), réduisant le temps passé à se connecter et à mémoriser les mots de passe, ce qui crée à son tour une expérience utilisateur globale plus fluide et plus simple. Par exemple, de nombreux clients abandonnent leur panier lorsqu'ils font des achats en ligne parce qu'ils ont oublié leur mot de passe, mais la SSO offre un processus plus simple et sans frustration, ce qui permet de fidéliser vos clients, d'augmenter les taux de conversion et d'accroître la visibilité de votre marque.

Sécurité renforcée

Les capacités d'authentification unique (SSO) de l'OIDC réduisent considérablement la probabilité d'un piratage lié au mot de passe. Avec l'authentification unique (SSO), les utilisateurs n'ont besoin de mémoriser qu'un seul mot de passe pour toutes leurs applications et sont moins susceptibles de réutiliser les mots de passe ou de les récupérer, ce qui réduit le risque de vol. Un accès facile est particulièrement précieux pour les collaborateurs qui sont sur le terrain ou qui travaillent sur plusieurs appareils.

Expérience utilisateur améliorée

Cette solution peut également réduire les coûts informatiques en diminuant le nombre de mots de passe requis à un seul, et peut aussi être utilisée pour renforcer les partenariats B2B. L'utilisation d'une SSO fédérée (ou d'une gestion d'identité fédérée) via l'OIDC peut aider à distinguer les organisations et les tiers, tels que les fournisseurs d'applications ou les partenaires, tout en partageant les identités et en authentifiant les utilisateurs au sein des domaines. Lorsque deux domaines sont fédérés, un utilisateur peut s'authentifier auprès d'un domaine et ensuite accéder aux ressources de l'autre domaine sans avoir à se reconnecter.

Pourquoi utiliseriez-vous OIDC ?

À l'instar d'autres solutions SSO, l'utilisation de l'OIDC offre les avantages suivants :

• Permet une SSO transparente sur plusieurs applications et services, ce qui crée une expérience utilisateur plus harmonieuse.
  
  
• Permet aux organisations de gérer plus efficacement les informations des utilisateurs de leurs clients, utilisateurs gratuits et/ou employés.
  
  
• Diminue considérablement la probabilité de piratage lié aux mots de passe, améliorant ainsi la sécurité sans affecter le parcours de l'utilisateur.
  
  

OIDC est unique parce que :

• Il s'agit d'une norme industrielle largement disponible sur un large éventail de plateformes, y compris les fournisseurs de messagerie électronique populaires et les réseaux de médias sociaux.
  
  
• Il est conçu sur le protocole OAuth 2.0, ajoutant l’authentification et la gestion d’identités. Les flux OIDC peuvent obtenir un jeton d'accès, utile si vous utilisez également des API.
  
  
• Il vérifie avec plus de certitude qui donne l’autorisation d’accéder aux ressources protégées.

Comment fonctionne OpenID Connect (OIDC) ?

Une solution OIDC permet à l'OP de déterminer les méthodes d'authentification disponibles lorsque les utilisateurs se connectent. Ils peuvent également demander le consentement de l'utilisateur pour partager des informations d'identité avec la partie de confiance.  En outre, l'OP peut offrir une gamme d'options d'authentification, notamment :

• Sans mot de passe, notamment les clés de sécurité FIDO
• Mots de passe à usage unique (OTP)
• Codes générés par l'application
• Les facteurs biométriques, notamment les empreintes digitales ou la reconnaissance faciale
• La connexion fédérée, notamment la SSO d'entreprise ou les OP tiers

La partie utilisatrice peut influencer le processus d'authentification de l'OP, par exemple en exigeant une authentification multifacteur (MFA). Cependant, la manière spécifique dont les OP gèrent l'authentification des utilisateurs ne relève pas du champ d'application du protocole OIDC.

Étant donné que l'OICD est conçu sur OAuth 2.0, il bénéficie du cadre bien établi d'OAuth 2.0, qui accorde en toute sécurité l'accès aux ressources sans exposer les identifiants des utilisateurs. OAuth 2.0 gère les autorisations (quelles données ou ressources peuvent être consultées), tandis que l'OIDC ajoute l'authentification (en s'assurant que l'utilisateur est bien celui qu'il prétend être). L'OIDC est similaire à OAuth 2.0 en ce sens que les utilisateurs donnent à une application la permission d'accéder aux données ou aux ressources d'une autre application sans avoir à fournir leurs identifiants et mots de passe. Au lieu de cela, les jetons sont utilisés pour compléter les processus d'authentification et d'autorisation :

• Les jetons d'identité, destinés à être lus par le client, prouvent que les utilisateurs ont été authentifiés et sont des jetons Web JSON (JWT) ou « jots ». Ces fichiers contiennent des informations sur l'utilisateur, telles que leurs noms d'utilisateur, le moment où ils ont tenté de se connecter à l'application ou au service, et la durée pendant laquelle il est autorisé à accéder aux ressources en ligne.
  
  
• Les jetons d'accès sont utilisés pour accéder aux ressources protégées, lesquelles doivent être lues et validées par l'API. Ces jetons peuvent être des JWT ou un format différent. Leur objectif est d'informer l'API que le détenteur de ce jeton a été autorisé à accéder à l'API et à exécuter des actions spécifiques (comme spécifié par le champ d'application qui a été accordé).

Les jetons d'identification ne peuvent pas être utilisés pour l'accès à l'API et les jetons d'accès ne peuvent pas être utilisés pour l'authentification. Le diagramme suivant montre comment fonctionne un processus d'authentification OIDC typique.

Flux OpenID Connect

Il est crucial de comprendre les différents flux OIDC pour vous assurer de choisir la bonne méthode d'authentification pour votre application, en gardant à l'esprit la sécurité, l'expérience utilisateur et la conformité. Étant donné que l'OIDC a cessé d'utiliser les autorisations et que le flux implicite OAuth 2.0 a été déprécié pour des raisons de sécurité, l'OIDC met désormais l'accent sur des options plus fiables, telles que le Proof Key for Code Exchange (PKCE), qui aide à prévenir les attaques de type Cross-Site Request Forgery (CSRF) et les attaques d'injection de code d'autorisation.

Flux d'authentification OIDC

Cette méthode est couramment utilisée pour les applications web nécessitant une communication sécurisée avec les fournisseurs d'identité. Elle fonctionne à l'aide d'un processus en trois étapes, où des codes d'autorisation à usage unique sont envoyés au lieu des détails de l'utilisateur. Ces codes sont ensuite échangés contre des jetons d'accès OAuth 2.0, permettant à l'application de s'authentifier en toute sécurité avec son identifiant client et son secret. Cette méthode garantit que le navigateur n'a pas d'accès direct aux jetons, renforçant ainsi la sécurité tout en permettant au fournisseur d'identité de confirmer la légitimité de l'application.

Flux de codes d'autorisation OIDC

Ce flux est couramment utilisé pour les applications côté serveur. Il fonctionne en permettant aux applications de demander des codes d'autorisation à un endpoint d'autorisation, qui peuvent ensuite être échangés contre des jetons d'identité ou des jetons d'accès OAuth 2.0 selon les besoins. Les applications clientes peuvent également utiliser le PKCE pour empêcher les injections de code non autorisées.

Étant donné que les jetons d'identité et d'accès ne sont pas exposés au navigateur, les jetons d'actualisation peuvent être exploités pour effectuer des actions au nom de l'utilisateur, même lorsqu'ils ne sont plus actifs. Ce flux est destiné aux clients qui peuvent protéger en toute sécurité un « secret client », une clé confidentielle ou un mot de passe utilisé dans OAuth 2.0, entre eux et le serveur d'autorisation. Une planification minutieuse et une surveillance continue sont cruciales pour garantir sa sécurité.

Flux hybride OIDC

Conçu pour les clients qui doivent traiter un code d'autorisation avant de l'échanger contre des jetons ou des données non sensibles, ce flux permet aux endpoints d'autorisation de renvoyer à la fois des codes d'autorisation et des jetons, la validation du nonce et les contrôles de hachage du code étant effectués au cours du processus pour en garantir l'intégrité. Les applications clientes peuvent également utiliser le PKCE pour empêcher les injections de code non autorisées.

Bien que ce flux offre une certaine flexibilité, il n'est pas adapté aux données sensibles en raison de l'exposition des jetons au navigateur. Comme le flux de code d'autorisation, il permet des actions hors ligne au nom des utilisateurs, ce qui en fait le choix idéal pour les clients confidentiels capables de gérer la sécurité efficacement.

Flux implicite OIDC

Conçu pour les données non sensibles et les applications basées sur un navigateur, il permet aux endpoints d'autorisation de demander directement des jetons d'identité, avec la possibilité de demander des jetons d'accès OAuth 2.0 si nécessaire.

Cependant, le flux est perçu comme une option moins sécurisée car les jetons sont exposés au navigateur et à son code sous-jacent. Cela élargit considérablement la surface d'attaque, donc l'utilisation doit être réservée aux jetons qui ne contiennent aucune donnée sensible, y compris les informations à caractère personnel (PII), et pour la validation par numéro à usage unique (nonce).

Il est important de noter que les meilleures pratiques de sécurité actuelles d'OAuth 2.0 ne recommandent pas l'utilisation du flux implicite pour des raisons de sécurité, et qu'il est largement déprécié en faveur d'options plus sûres comme le flux de code d'autorisation avec le PKCE.

Différences entre SAML, OAuth 2.0 et OpenID Connect

OpenID Connect contre OAuth 2.0

OAuth 2.0 est un cadre de norme ouverte pour l'autorisation des API. Il définit comment un client d'API peut obtenir des jetons de sécurité contenant un ensemble d'autorisations pour les ressources disponibles via cette API.

Au lieu d'exiger qu'un utilisateur partage ses identifiants de connexion avec une application pour permettre à cette application d'accéder à une autre, OAuth 2.0 délègue les décisions d'autorisation à un serveur d'autorisation distinct qui héberge le compte utilisateur. En bref, OAuth 2.0 agit au nom de l'utilisateur, en fournissant un accès délégué à un service tiers sans que l'utilisateur n'expose ses informations d'identification à ce tiers.

La principale différence est qu'OAuth 2.0 est un cadre d'autorisation utilisé pour protéger les ressources, tandis que l'OIDC est un protocole d'authentification superposé à OAuth 2.0 pour gérer la connexion des utilisateurs. Le SAML, quant à lui, est une norme d'identité fédérée qui couvre à la fois l'authentification et l'autorisation.

Quelle est la différence entre SAML et OIDC ?

Les SAML et OIDC sont deux protocoles d’authentification puissants utilisés pour créer des expériences de connexion sécurisées, mais ils servent à des fins différentes.

• Le SAML est une norme plus ancienne et plus largement adoptée par les entreprises qui utilisent des applications basées sur le web, tandis que l'OIDC est plus récent et gagne du terrain avec les applications mobiles et natives.
  
  
• Le SAML est principalement utilisé pour les applications basées sur un navigateur et peut être utilisé sur les appareils mobiles via la SSO basée sur le navigateur, bien qu'il ne prenne pas en charge nativement l'accès aux API. OAuth 2.0 offre un accès aux API et l'OIDC permet l'accès aux API, aux applications mobiles natives et aux applications basées sur le navigateur.
  
  
• L'OIDC peut utiliser des OP publics tiers, tels que Google et Microsoft, ou des OP privés dans des environnements d'entreprise pour authentifier les utilisateurs. Avec l'OIDC, un utilisateur peut accéder à une application en se connectant à l'aide d'un compte fiable et compatible avec l'OIDC.
  
  
• Pour les grandes entreprises qui nécessitent un niveau de sécurité plus élevé, le SAML pourrait être le choix idéal. Le SAML permet l'authentification multifacteur, est riche en fonctionnalités et constitue un élément essentiel de la sécurité des entreprises depuis plus de dix ans.
  
  
• Il est connu pour sa flexibilité, mais la plupart des développeurs trouvent que l'OIDC est moins complexe.
  
  
• Le SAML utilise des jetons écrits en XML et OIDC utilise des JWT, qui sont portables et supportent une gamme d'algorithmes de signature et de chiffrement.
  
  

Les autres différences incluent :

• Le SAML est réputé pour sa flexibilité, mais la plupart des développeurs trouvent que l'OIDC est plus simple à utiliser car il est moins complexe.
  
  
• Il est utilisé pour accéder aux applications basées sur un navigateur et ne prend pas en charge la SSO pour les appareils mobiles ni ne fournit d'accès à l'API. OAuth 2.0 offre un accès aux API et l'OIDC permet l'accès aux API, aux applications mobiles natives et aux applications basées sur le navigateur.
  
  
• L'OIDC porte sur l'identité d'une personne. OAuth 2.0 porte sur ce qu'ils sont autorisés à faire.
  
  
• Le SAML utilise des jetons écrits en XML et OIDC utilise des JWT, qui sont portables et supportent une gamme d'algorithmes de signature et de chiffrement.
  
  

Avantages de l'OIDC pour les développeurs

L’OIDC est l’une des normes de sécurité les plus récentes et est utilisée par les développeurs qui prennent en charge les applications mobiles, les API et les applications basées sur un navigateur. D’autres avantages incluent :

Il n'est plus nécessaire de gérer les mots de passe

Étant donné que les jetons sont utilisés pour compléter les processus d’authentification et d’autorisation au lieu des noms d’utilisateur et des mots de passe, les développeurs ne sont plus responsables de la configuration, du stockage et de la gestion des mots de passe, ce qui est souvent à l’origine des violations de données basées sur les identifiants.

Une sécurité renforcée

L'utilisation de jetons en fait un protocole très sécurisé. Non seulement les identifiants des utilisateurs ne sont pas partagés, mais cela permet également aux utilisateurs de se connecter à plusieurs applications sans avoir à créer des noms d'utilisateur et des mots de passe distincts pour chacune, qui peuvent facilement être compromis.

Facilité de mise en œuvre

L'OIDC est un protocole d'authentification décentralisé et à norme ouverte qui permet aux sites web et aux services d'authentification d'échanger des informations de manière sécurisée et standardisée.