SAML vs OpenID (OIDC)

Il existe un petit univers de protocoles/standards d’identité et d’authentification, chacun ayant ses propres avantages et différences. Cet article explore la comparaison entre SAML et OpenID Connect (OIDC), les scénarios dans lesquels l’un ou l’autre protocole serait bénéfique pour votre organisation, et la manière dont chacun contribue à la gestion des identités et des accès (IAM). Chaque approche permet l’authentification unique (SSO), mais il existe des différences techniques et idéologiques distinctes à évaluer avant de commencer votre projet : SAML est plus spécialisé dans l’octroi sécurisé de l’accès à un site Web à travers des domaines, tandis que OIDC fournit un contexte supplémentaire pour les applications mobiles et Web.

SAML vs OpenID (OIDC)

Cet article pourrait simplement proposer une comparaison entre le Security Assertion Markup Language (SAML 2.0) et OAuth (Open Authorization). OAuth est la base d’OIDC, mais OIDC étend la première avec une couche d’identité pour authentifier vos comptes d’utilisateur existants en utilisant un service décentralisé qui est géré par une fondation à but non lucratif nommée OpenID Foundation. La communauté open source a initié le développement d’OpenID en 2005 avec pour objectif que les identités soient décentralisées et ne soient pas détenues par une tierce partie. Selon la fondation, il y a maintenant plus d’un milliard de comptes d’utilisateurs compatibles avec OpenID sur plus de 50 000 sites Web. Elle gère l’infrastructure qui supporte l’authentification OIDC, sa communauté et toute opération légale ou de gouvernance.

SAML 2.0, quant à lui, est une norme ouverte qui assure l’authentification et l’autorisation entre les fournisseurs d’identité (IdP) et les fournisseurs de services (SP) commerciaux et privés depuis 2003. Au départ, il s’agissait d’un moyen de mettre en œuvre le SSO à l’aide d’un cadre basé sur XML pour permettre aux fournisseurs d’identité et aux services d’exister séparément les uns des autres, avec une gestion centralisée des utilisateurs. Commençons par examiner le fonctionnement de SAML, en l’explorant composant par composant.

Comment fonctionne SAML ?

SAML est une norme ouverte d’authentification (et d’autorisation, le cas échéant) qui fournit un accès SSO aux applications Web par le biais de la fédération d’identités. SAML relaie les informations d’identification des utilisateurs depuis un IdP qui possède et maintient les identités pour vérifier les droits d’accès et les SP. Les fournisseurs de services exigent une authentification avant d’accorder aux utilisateurs l’accès à la ressource. Chaque utilisateur (ou groupe) possède des attributs qui décrivent les informations de son profil et affirment ce à quoi il est exactement autorisé à accéder.

SAML utilise des documents de métadonnées (jetons SAML) en langage de balisage extensible (XML) pour un processus d’assertion permettant de vérifier l’identité d’un utilisateur et ses privilèges d’accès.

Les développeurs utilisent des plugins SAML dans les applications ou les ressources pour une expérience de connexion SSO qui garantit que les pratiques de sécurité sont respectées et que les informations d’identification/assertions déterminent qui peut accéder à une application. En outre, SAML peut être utilisé pour contrôler les ressources auxquelles une identité peut accéder dans une application.

SAML est composé de plusieurs éléments de base qui permettent d’échanger des informations sur les utilisateurs pour le contrôle d’accès, notamment l’IdP, le client, les attributs et le SP.

Fournisseur d’identités (IdP)

Un IdP est un service qui maintient et gère les identités numériques pour vérifier les informations d’identification des utilisateurs dans les applications, les réseaux et les services Web. Son rôle principal est de protéger l’intégrité des informations d’identification des utilisateurs et de fédérer l’identité des utilisateurs lorsque des connexions SSO sont souhaitées.

Client

Les clients sont vos utilisateurs qui s’authentifient dans un service en utilisant les informations d’identification gérées par un IdP. Par exemple, votre employeur peut utiliser SAML pour l’accès SSO aux services dont vous avez besoin pour travailler, en utilisant l’adresse électronique et le mot de passe de votre entreprise.

Attribut

SAML transfère des messages, appelés assertions, d’un IdP à un fournisseur de services. Ces assertions définissent toutes les exigences de sécurité pertinentes pour la transaction en authentifiant, en autorisant et en déterminant le niveau des autorisations qu’un client recevra. Des attributs tels que « dept », « email » et « role » sont utilisés pour appliquer la gestion et le contrôle des accès. Parfois, des attributs personnalisés sont utilisés afin que SAML puisse être étendu puis utilisé avec des logiciels personnalisés.

Fournisseur de services (SP)

Les fournisseurs de services sont une ressource à laquelle les utilisateurs s’authentifient à l’aide de SAML SSO, généralement un site Web ou une application privée. Ils reçoivent, acceptent ou refusent les assertions des IdP pour chaque profil client avant d’accorder l’accès aux utilisateurs. Les SP envoient des requêtes aux IdP pour commencer le processus d’authentification, et l’assertion du client est reçue en réponse. Le processus est parfois inversé lorsqu’un IdP initie le flux d’ouverture de session pour confirmer l’identité de l’utilisateur. Il peut être initié dans les deux sens.

Comment fonctionne OIDC

OIDC étend le protocole OAuth de sorte que les services clients (vos applications) vérifient l’identité des utilisateurs et échangent des informations de profil par l’intermédiaire de fournisseurs OpenID via des API RESTful qui envoient des jetons Web JSON (JWT) pour partager des informations pendant le processus d’authentification. Les fournisseurs sont essentiellement des serveurs d’authentification. De nombreux développeurs sont attirés par cette approche car elle est hautement évolutive, flexible sur toutes les plateformes et relativement simple à mettre en œuvre. Ses principaux composants sont un flux d’identification unique de l’utilisateur avec des bases OAuth.

Authentification de l’utilisateur

Un propriétaire de ressources (vos utilisateurs) s’authentifie et est autorisé à accéder à une application client par le biais d’un serveur d’autorisation qui accorde un jeton d’accès permettant aux applications de recevoir des informations consenties depuis un point de terminaison UserInfo. Ce dernier est une ressource protégée trouvée sur un serveur OpenID qui contient des déclarations (assertions) sur chaque utilisateur dans un objet JSON. Les informations d’authentification sont ensuite encodées dans un jeton d’identification reçu par l’application. Ces informations sont mises en cache pour des performances évolutives et personnalisent l’expérience de l’utilisateur final.

Fondé sur le protocole OAuth 2.0

L’OIDC repose sur le cadre OAuth 2.0, une norme qui permet aux applications et services tiers d’accéder aux ressources d’identification des utilisateurs. Aucune information d’identification de l’utilisateur n’est envoyée sur le réseau ou stockée sur des serveurs tiers, ce qui accroît la sécurité et la facilité d’utilisation pour les administrateurs informatiques.

Similitudes

• Les deux cadres sont des protocoles d’identité qui rendent le SSO possible.
• Les deux cadres sont sûrs, bien documentés et matures.
• Les utilisateurs s’authentifient via un IdP, généralement une fois, et peuvent ensuite accéder à d’autres applications qui « font confiance » à l’IdP. Certains services de Zero Trust s’authentifient à chaque point de la chaîne et vérifient périodiquement l’accès à l’aide d’une autre méthode d’authentification.
• Le flux de travail de connexion peut sembler très similaire aux yeux de l’utilisateur final, qui n’a aucune connaissance des multiples techniques variées qui se déploient en coulisses.

Différences

• De nombreux développeurs pensent qu’OpenID Connect est plus simple à mettre en œuvre car il n’y a pas de manipulation XML.
• OpenID ne dispose pas de données d’autorisation des utilisateurs (telles que les permissions) et se concentre principalement sur l’affirmation d’identité. SAML est un échange de données d’identité et est très riche en fonctionnalités.
• L’authentification est décentralisée avec OpenID.
• SAML a recours à des assertions par opposition à l’architecture de jetons d’identification utilisée par OpenID et OAuth.
• OIDC est conçu pour les charges de travail des API et peut être utilisé pour sécuriser les API.

Cas d’utilisation

Les développeurs et les services informatiques doivent choisir la solution qui convient le mieux à leur(s) cas d’utilisation particuliers. Cependant, il est parfois possible d’en utiliser plusieurs simultanément. Quoi qu’il en soit, les cas d’utilisation se sont développés de manière organique, l’OIDC étant utilisé pour les applications Web et mobiles de canal arrière qui demandent des jetons d’accès.

SAML est presque toujours utilisé pour l’accès au site Web du canal frontal où les utilisateurs sont ceux qui déclenchent l’authentification de l’application. Dans ce dernier cas, on suppose que les applications clientes (un service Web) fonctionnent à partir de appareils différents de ceux du propriétaire de la ressource (vous). Vous trouverez ci-dessous quelques directives générales pour les cas d’utilisation :

• Une application mobile utilise généralement un service tel que l’OIDC, parce qu’il est plus léger et que de nombreuses fonctions utilisées par les développeurs sont préétablies ou disponibles dans des bibliothèques complémentaires.
• Les applications qui intègrent SAML sont une évidence, il suffit d’utiliser SAML.
• Utilisez SAML pour accéder aux applications d’entreprise via un portail.
• La protection des API ou l’exposition des API sont des services qui nécessiteront OAuth 2.0 ou OIDC.
• Les entreprises privilégient parfois SAML en raison de sa capacité de personnalisation et de sa priorité accordée à l’échange sécurisé de données. Les secteurs réglementés devraient presque toujours opter pour SAML afin de protéger les informations sensibles des utilisateurs.

Utilisation conjointe d’OIDC et de SAML

Ces protocoles ne s’excluent pas mutuellement. Envisagez d’utiliser SAML pour le SSO d’entreprise afin de sécuriser l’accès aux ressources de votre organisation et OIDC pour les cas d’utilisation mobile qui ont des exigences d’évolutivité élevées. Chacun de ces protocoles présente des avantages inhérents et chacun peut fournir des services de SSO.

En savoir plus

Si vous souhaitez en savoir plus sur la manière de combiner le meilleur des deux mondes, en utilisant SAML et OIDC, contactez-nous. La plateforme JumpCloud utilise les attributs des utilisateurs pour faire des suggestions intelligentes d’appartenance à un groupe, et bien plus encore. Vous pouvez également explorer ce que JumpCloud a à offrir en programmant une démonstration personnalisée gratuite.