Il existe un petit univers de protocoles/normes 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 chaque protocole bénéficierait à 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 diverses différences techniques et idéologiques qui doivent être évaluées avant de démarrer votre projet : SAML est plus spécialisé dans la fourniture sécurisée d’un accès à des sites Web inter-domaines, tandis qu’OIDC fournit un contexte supplémentaire pour les appareils mobiles et des applications Web.
SAML contre OpenID (OIDC)
Cet article peut simplement proposer une comparaison entre Security Assertion Markup Language (SAML 2.0) et OAuth (Open Authorization). OAuth est le fondement d’OIDC, mais OIDC étend le premier avec une couche d’identité pour authentifier vos comptes d’utilisateurs existants à l’aide d’un service décentralisé géré par une fondation à but non lucratif appelée OpenID Foundation. La communauté open source a lancé le développement d’OpenID en 2005 dans le but de rendre l’identité décentralisée et non détenue par un tiers. Selon la fondation, il existe désormais plus d’un milliard de comptes d’utilisateurs compatibles OpenID sur plus de 50 000 sites Web. Il gère l’infrastructure qui prend en charge l’authentification OIDC, sa communauté et toute opération juridique ou de gouvernance.
SAML 2.0, quant à lui, est un standard ouvert qui fournit l’authentification et l’autorisation entre les fournisseurs d’identité (IdP) commerciaux et privés et les fournisseurs de services (SP) depuis 2003. Il s’agissait à l’origine d’un moyen de mettre en œuvre le SSO à l’aide d’un cadre basé sur XML. qui permet 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’examinant 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 via la fédération d’identité. SAML relaie les informations d’identification de l’utilisateur de l’IdP qui possède et gère l’identité 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 indiquent exactement à quoi il est autorisé à accéder.
SAML utilise des documents de métadonnées XML (Extensible Markup Language) (jetons SAML) pour un processus d’assertion permettant de vérifier l’identité de l’utilisateur et les privilèges d’accès.
Les développeurs utilisent des plugins SAML dans les applications ou les ressources pour la connexion SSO, ce qui garantit que les pratiques de sécurité sont suivies et que les informations d’identification/assertions déterminent qui a accès à une application. De plus, SAML peut être utilisé pour contrôler les ressources auxquelles une identité a accès dans l’application.
SAML se compose de plusieurs éléments de base qui permettent l’échange d’informations utilisateur pour le contrôle d’accès, notamment l’IdP, le client, les attributs et le SP.
Fournisseur d’identité (IdP)
Un IdP est un service qui prend en charge et gère les identités numériques pour vérifier les informations d’identification des utilisateurs sur 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 d’unifier l’identité des utilisateurs lorsque des connexions SSO sont souhaitées.
Client
Les clients sont vos utilisateurs qui s’authentifient auprès d’un service à l’aide d’informations d’identification gérées par l’IdP. Par exemple, votre employeur peut utiliser SAML pour accéder aux services SSO dont vous avez besoin pour travailler en utilisant l’adresse e-mail et le mot de passe de votre entreprise.
Attribut
SAML transfère des messages, appelés assertions, de l’IdP à un fournisseur de services. Ces assertions définissent toutes les exigences de sécurité associées à la transaction par authentification, autorisation et spécifiant le niveau d’autorisations dont le client sera accordé. Des attributs tels que « département », « e-mail » et « rôle » sont utilisés pour appliquer la gestion et le contrôle des accès. Les attributs personnalisés sont parfois utilisés pour que SAML puisse être étendu puis utilisé avec un logiciel personnalisé.
Fournisseur de services (SP)
Les fournisseurs de services sont une ressource auprès de 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 IdP pour chaque profil client avant d’accorder l’accès aux utilisateurs. Les SP envoient des requêtes aux IdP pour démarrer le processus d’authentification, et l’assertion du client est reçue en réponse. Le processus s’inverse parfois lorsque l’IdP lance le flux de connexion pour vérifier l’identité de l’utilisateur. Elle peut être initiée dans les deux sens.
Comment fonctionne l’OIDC
OIDC étend le protocole OAuth afin que les services clients (vos applications) puissent vérifier les identités des utilisateurs et échanger des informations de profil via des 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 plates-formes et relativement facile à mettre en œuvre. Ses principaux composants sont un flux d’authentification utilisateur unique avec les bases d’OAuth.
Authentification d’utilisateur
Un propriétaire de ressource (vos utilisateurs) authentifie et accède à une application client via un serveur d’autorisation qui fournit un jeton d’accès permettant aux applications d’obtenir des informations d’approbation à partir d’un point de terminaison UserInfo. Cette dernière est une ressource sécurisée exposée sur un serveur OpenID qui contient des déclarations (assertions) pour chaque utilisateur dans un objet JSON. Les informations d’authentification sont ensuite codé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.
Basé sur le protocole OAuth 2.0
OIDC est construit sur le framework OAuth 2.0, une norme qui permet aux applications et services tiers d’accéder aux informations 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 augmente la sécurité et la facilité d’utilisation pour les administrateurs informatiques.
Similitudes
- Les deux frameworks sont des protocoles d’identité qui rendent le SSO possible.
- Les deux frameworks sont sécurisés, bien documentés et matures.
- Les utilisateurs s’authentifient via l’IdP, généralement une fois, et peuvent ensuite accéder à d’autres applications qui « font confiance » à l’IdP. Certains services 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 à l’utilisateur final qui n’a aucune connaissance des techniques nombreuses et variées qui se déroulent en coulisses.
Différences
- De nombreux développeurs trouvent qu’OpenID Connect est plus facile à mettre en œuvre car il n’y a aucune manipulation XML.
- OpenID ne dispose d’aucune donnée d’autorisation utilisateur (telle que les autorisations) et se concentre principalement sur l’authentification de l’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 utilise des assertions contrairement à l’architecture de jeton d’identification utilisée par OpenID et OAuth.
- OIDC est conçu pour les charges de travail API et peut être utilisé pour sécuriser les API.
Cas d’utilisation
Les développeurs et les services informatiques doivent choisir la solution la mieux adaptée à leurs cas d’utilisation spécifiques. Cependant, il est parfois possible d’en utiliser plusieurs en même temps. Néanmoins, 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 nécessitent des jetons d’accès.
SAML est presque toujours utilisé comme canal frontal pour accéder aux sites Web sur lesquels ce sont les utilisateurs qui déclenchent l’authentification de l’application. Dans ce dernier cas, les applications clientes (service Web) sont supposées s’exécuter à partir d’appareils autres que 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 comme OIDC car il est plus léger et de nombreuses fonctionnalités utilisées par les développeurs sont pré-construites ou disponibles dans des bibliothèques complémentaires.
- Les applications qui intègrent SAML sont transparentes, utilisez simplement SAML.
- Utilisez SAML pour accéder aux applications d’entreprise via un portail.
- La protection API ou l’exposition API sont des services qui nécessiteront OAuth 2.0 ou OIDC.
- Les entreprises préfèrent parfois SAML en raison de sa personnalisation et de l’accent mis sur l’échange de données sécurisé. Les industries réglementées devraient presque toujours choisir SAML pour protéger les informations sensibles des utilisateurs.
Utiliser OIDC et SAML ensemble
Ces protocoles ne s’excluent pas mutuellement. Envisagez d’utiliser SAML pour l’authentification unique d’entreprise afin de fournir un 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 SSO.
En savoir plus
Si vous souhaitez en savoir plus sur la façon de combiner le meilleur des deux mondes en utilisant SAML et OIDC, contactez-nous. La plateforme JumpCloud utilise les attributs utilisateur pour faire des suggestions intelligentes d’adhésion à un groupe et bien plus encore. Vous pouvez également découvrir ce que JumpCloud a à offrir en planifiant une démo personnalisée gratuite.