OIDC et SAML

OpenID Connect (OIDC) et Security Assertion Markup Language (SAML) sont deux protocoles d’authentification qui permettent aux fournisseurs d’identités (IdP) de mettre en œuvre la validation des utilisateurs et le contrôle d’accès. Chacun définit son propre mécanisme pour gérer les identités virtuelles des utilisateurs vérifiés, qui sont ensuite utilisées pour accorder ou refuser l’accès aux applications protégées.

Un fournisseur d’identités gère une base de données des informations d’identité des utilisateurs. Un prestataire de services (SP) s’appuie sur ces informations pour authentifier un utilisateur, parfois une seule fois pour plusieurs applications (authentification unique). Les protocoles OIDC et SAML sont des normes qui définissent précisément comment ces informations doivent circuler entre ces deux parties. L’objectif final est le même pour les deux : l’authentification de l’utilisateur. Mais la méthodologie sous-jacente pour atteindre l’objectif est différente.

L’authentification est un processus par lequel l’identité d’un utilisateur ou d’un processus peut être validée. Il s’agit généralement de restreindre l’accès aux applications et/ou aux ressources protégées.

SAML 2.0, qui est la version actuelle de la norme, existe depuis 2005. Ce protocole utilise le langage XML pour formater les informations relatives aux identités. XML est une norme établie de formatage des informations qui encode les documents afin qu’ils soient facilement compréhensibles à la fois par les humains et les ordinateurs. Pour transférer ou recevoir des informations encodées en XML, elle utilise des requêtes SOAP ou HTTP de base. Le service qui demande des informations sur les identités est défini par le contrat SAML comme un prestataire de services. Voici à quoi ressemble un flux d’authentification SAML typique :

1. Avant que le prestataire de services ne puisse s’adresser au fournisseur d’identités pour la vérification des identités, les deux parties doivent d’abord apprendre à mieux se connaître. Pour ce faire, elles échangent des informations préliminaires, via des métadonnées, qui comprennent des détails :

   • Clés publiques (utilisées pour le chiffrement)

   • Algorithmes de chiffrement pris en charge

   • URL des terminaux (où envoyer les messages SAML)

   • Méthodes de connexion prises en charge

   • Formats d’attributs XML pris en charge

Une fois que le prestataire de services et le fournisseur d’identités ont pris connaissance de ces informations, ils se reconfigurent en conséquence.

2. Lorsqu’un utilisateur tente de se connecter, le prestataire de services envoie une demande d’authentification au fournisseur d’identités. Cette demande est connue sous le nom de SAML AuthnRequest.

3. Le fournisseur d’identités vérifie l’identité de l’utilisateur, crée une réponse SAML encodée, connue sous le nom d’assertion SAML, puis la renvoie au prestataire de services.

4. Le prestataire de services analyse le code XML de l’assertion SAML et, en fonction de la réponse, accorde ou refuse l’accès utilisateur à l’application.

Protocole relativement récent, mais bien géré, l’OIDC s’appuie sur la structure OAuth 2.0. L’OIDC utilise des jetons web basés sur JSON (JWT) pour structurer les données. La norme du secteur JWT définit les règles de représentation et de transfert sécurisé des demandes entre deux parties. Les demandes sont des données utilisateur sensibles et chiffrées, utilisées pour la gestion et la vérification des identités. Pour le transport, l’OIDC utilise les flux HTTPS par défaut.

Les champs d’application de l’OIDC définissent les demandes (les attributs utilisateur) auxquelles une application peut avoir accès. Le fournisseur d’identités tient à jour une liste des champs d’application acceptables, et une application peut choisir ceux qu’elle souhaite demander, en fonction de ses besoins. Après qu’un utilisateur a explicitement consenti au partage de ses données (qui comprennent les champs d’application), le fournisseur d’identités met les champs d’application à la disposition de l’application.

Pour mieux comprendre le fonctionnement des champs d’application dans un flux OIDC standard, considérons une application web qui authentifie un utilisateur en fonction de son nom d’utilisateur et de son mot de passe. Après l’authentification, elle lui envoie également une série d’e-mails de bienvenue.

(Remarque : l’OIDC prend en charge différents flux d’authentification. Vous trouverez ci-dessous un exemple du flux OIDC le plus simple, connu sous le nom de flux implicite.)

1. Comme pour SAML, la partie de confiance (RP) et le fournisseur d’identités doivent échanger des métadonnées avant de pouvoir communiquer. Pour l’OIDC, cependant, les exigences minimales en matière d’échange de métadonnées sont relativement plus simples. Comme les deux parties doivent se mettre d’accord sur les champs d’application possibles, le fournisseur d’identités doit attribuer un secret et un ID client à la partie de confiance, laquelle doit partager le terminal sur lequel elle souhaite recevoir des codes et/ou des jetons.

2. Lorsqu’un utilisateur se connecte à l’application, celle-ci le redirige vers le fournisseur d’identités. Il inclut l’ID client, ainsi que les champs d’application demandés, qui, dans notre cas, sont l’adresse e-mail de l’utilisateur.

3. À son tour, le fournisseur d’identités redirige l’utilisateur vers l’écran de connexion.

4. Une fois que son identité a été vérifiée, l’utilisateur est invité à accorder à l’application l’accès à ses données (spécifiées par les champs d’application demandés).

5. Si l’utilisateur autorise l’accès, les valeurs des champs d’application sont mises à la disposition de l’application via le terminal préconfiguré.

6. L’application peut utiliser l’adresse e-mail de l’utilisateur pour lui envoyer la séquence de bienvenue.

• La norme SAML étant plus ancienne, il est très difficile de l’utiliser pour authentifier des types d’applications modernes comme les applications monopage et les applications pour smartphones. Elle n’a tout simplement pas été conçue à cet effet. À l’inverse, le protocole OIDC est idéal pour ce type d’applications.

• L’OIDC utilise des jetons JWT, qui sont plus petits et nécessitent un traitement léger. D’autre part, les documents XML utilisés par la norme SAML sont beaucoup plus volumineux et relativement difficiles à traiter.

• Par défaut, l’OIDC prend en charge le consentement de l’utilisateur. Il est possible d’obtenir le même résultat avec SAML, mais cela nécessite un développement manuel important.

• Comme la norme SAML existe depuis bien plus longtemps, de nombreuses organisations, y compris des entités gouvernementales, lui font encore confiance. Elle est certainement plus riche en fonctionnalités, mais l’OIDC commence à la rattraper.

• L’OIDC est beaucoup plus facile à configurer, en particulier dans un environnement centré sur le consommateur, où les fonctionnalités d’identité de base sont requises.

L’OIDC a été conçu pour être le remplaçant moderne de SAML, car il reproduit la plupart des cas d’utilisation fondamentaux de SAML, tout en réduisant la surcharge de traitement causée par les messages basés sur XML et SOAP. La plupart des failles de sécurité ne sont pas dues à des problèmes intrinsèques à l’une ou l’autre des deux normes, mais plutôt à des erreurs d’implémentation. Toutefois, on peut faire valoir que, la norme SAML étant beaucoup plus difficile à mettre en œuvre que l’OIDC, elle est également davantage sujette à des erreurs d’implémentation. En outre, de nombreuses menaces de sécurité et vulnérabilités associées à XML doivent être évitées lors de la mise en œuvre de SAML, ce qui accroît la complexité.

Inversement, le protocole OIDC étant basé sur OAuth 2.0, il intègre une grande partie du modèle de menace documenté et des considérations de sécurité. Le chiffrement de JSON est également beaucoup plus facile que celui de XML, ce qui, là encore, réduit les risques d’erreurs d’implémentation.

Grâce aux champs d’application, l’OIDC permet aux utilisateurs de choisir le niveau d’informations qu’ils souhaitent partager avec une application. Par exemple, une application ne demande à l’utilisateur que de partager son adresse e-mail, au lieu de partager l’ensemble de son profil. Cela établit un contrat gagnant-gagnant entre l’utilisateur et l’application ; l’application obtient ce dont elle a besoin pour améliorer l’expérience de l’utilisateur, et l’utilisateur ne partage qu’un minimum d’informations personnelles. Oui, cette fonctionnalité peut également être ajoutée aux systèmes basés sur SAML, mais cela nécessiterait un développement supplémentaire, car SAML ne la prend pas en charge dans sa version standard.

Les protocoles OIDC et SAML peuvent tous deux être utilisés pour mettre en œuvre l’authentification unique (SSO), qui réduit la nécessité de se connecter plusieurs fois et, par conséquent, diminue la probabilité d’attaques par hameçonnage. Cependant, ce n’est pas parce que la probabilité est faible qu’elles ne peuvent pas se produire. Le Cofense Phishing Defense Center a découvert une tactique d’hameçonnage qui manipulait l’OIDC pour révéler les données utilisateur, sans mot de passe, malgré l’authentification multifacteur. Des attaques par hameçonnage similaires ont également été menées sur des implémentations SAML dans le passé. Une fois de plus, il est difficile de dire si l’un des deux prévient mieux l’hameçonnage que l’autre ; cela dépend en grande partie des considérations de sécurité prises en compte lors de la mise en œuvre.

Les protocoles SAML et OIDC peuvent tous deux être utilisés pour mettre en œuvre l’authentification unique, ce qui signifie que l’utilisateur ne doit mémoriser qu’un seul mot de passe pour se connecter au service de gestion des accès et des identités (IAM). Cette connexion unique peut également être protégée en demandant aux utilisateurs de fournir un facteur d’authentification supplémentaire. Une fois que les utilisateurs sont connectés en toute sécurité au service IAM, ils peuvent accéder de manière transparente à toutes les applications protégées, sans avoir à entrer d’autres mots de passe. Cela permet d’éviter les attaques par force brute, dans lesquelles les attaquants entrent à plusieurs reprises des mots de passe potentiels dans l’espoir d’obtenir une correspondance. Pas de mot de passe = pas de risque d’attaque par force brute.

Les protocoles OIDC et SAML sont tous deux de puissantes technologies d’authentification dotées de fonctionnalités uniques. Celui que vous choisirez pour votre organisation dépend de vos besoins spécifiques. Si :

• Vous souhaitez mettre en place rapidement une plateforme d’identités, préférez sans hésitation l’OIDC à SAML. La mise en œuvre d’une solution OIDC de base est beaucoup plus simple que celle de SAML, qui nécessite un traitement XML lourd.

• Votre architecture est centrée sur les API, avec beaucoup d’applications mobiles et monopage, utilisez l’OIDC. Ce protocole garantira une expérience beaucoup plus efficace et interopérable.

• Vous souhaitez mettre en œuvre une norme mature, qui existe depuis longtemps, alors choisissez SAML. Riche en fonctionnalités, cette norme est efficace et constitue un élément essentiel des réseaux d’entreprise depuis plus d’une décennie.