Original OpenID 2.0 vs SAML
Ce sont deux protocoles d'authentification différents et ils diffèrent au niveau technique.
À distance, les différences commencent lorsque les utilisateurs initient l'authentification. Avec OpenID, une connexion utilisateur est généralement une adresse HTTP de la ressource responsable de l'authentification. D'autre part, SAML est basé sur une confiance explicite entre votre site et le fournisseur d'identité. Il est donc assez rare d'accepter des informations d'identification à partir d'un site inconnu.
Les identités OpenID sont faciles à naviguer sur le net. En tant que développeur, vous pouvez simplement accepter des utilisateurs provenant de fournisseurs OpenID très différents. D'autre part, un fournisseur SAML doit généralement être codé à l'avance et vous ne fédérez votre application qu'avec les fournisseurs d'identité sélectionnés. Il est possible de restreindre la liste des fournisseurs d'identité OpenID acceptés, mais je pense que cela irait à l'encontre du concept général OpenID.
Avec OpenID, vous acceptez les identités provenant de serveurs arbitraires. Quelqu'un prétend être http://someopenid.provider.com/john.smith. Comment allez-vous faire correspondre cela avec un utilisateur de votre base de données? D'une manière ou d'une autre, par exemple en stockant ces informations avec un nouveau compte et en les reconnaissant lorsque l'utilisateur visite à nouveau votre site. Notez que toute autre information sur l'utilisateur (y compris son nom ou son email) ne peut pas être fiable!
D'autre part, s'il existe une relation de confiance explicite entre votre application et le fournisseur d'identifiants SAML, vous pouvez obtenir des informations complètes sur l'utilisateur, notamment le nom et l'adresse de messagerie. Cette information peut être approuvée, uniquement en raison de la relation de confiance. Cela signifie que vous avez tendance à croire que le fournisseur d'identifiants a en quelque sorte validé toutes les informations et que vous pouvez vous y fier au niveau de l'application. Si les utilisateurs viennent avec des jetons SAML émis par un fournisseur inconnu, votre application refuse simplement l'authentification.
OpenID Connect vs SAML
(section ajoutée 07-2017, version élargie 08-2018)
Cette réponse date de 2011 et à ce moment, OpenID représentait OpenID 2.0 . Plus tard, vers 2012, OAuth2.0 a été publié et en 2014, OpenID Connect (chronologie plus détaillée ici ).
Aujourd'hui, pour tous ceux qui lisent ceci - OpenID Connect n'est pas le même OpenID que la réponse d'origine fait référence à, il s'agit plutôt d'un ensemble d'extensions à OAuth2.0.
Tandis que cette réponse peut apporter des éclaircissements du point de vue conceptuel, une version très concise pour quelqu'un venant avec OAuth2.0 est que OpenID Connect est en fait OAuth2.0 mais ajoute un moyen standard de interroger les informations utilisateur , après la disponibilité du jeton d'accès.
En ce qui concerne la question initiale, quelle est la principale différence entre OpenID Connect (OAuth2.0) et SAML? Comment la relation de confiance est-elle construite entre l'application et le fournisseur d'identité?
SAML construit la relation de confiance sur une signature numérique, les jetons SAML émis par le fournisseur d'identité sont des XML signés, l'application valide la signature elle-même et le certificat qu'elle présente. Les informations utilisateur sont incluses dans un jeton SAML, entre autres informations.
OAuth2 construit la relation de confiance sur un appel HTTP direct de l'application à l'identité. La demande contient le jeton d'accès (obtenu par l'application lors du flux de protocole) et la réponse contient les informations concernant l'utilisateur.
OpenID Connect étend cette possibilité pour permettre d’obtenir l’identité sans cette étape supplémentaire impliquant l’appel de l’application au fournisseur d’identité. L'idée est basée sur le fait que les fournisseurs OpenID Connect émettent en fait deux jetons, le
access_token, le même problème OAuth2.0 et le nouveau, leid_token, qui est un jeton JWT , signé par le fournisseur d'identité. L'application peut utiliser le jeton id pour établir une session locale, en fonction des revendications incluses dans le jeton JWT, mais le jeton id ne peut pas être utilisé pour interroger d'autres services, ces appels vers des services tiers doivent néanmoins utiliser le jeton d'accès. . Vous pouvez alors considérer OpenID Connect comme un hybride entre SAML2 (jeton signé) et OAuth2 (jeton d'accès), car OpenID Connect ne concerne que les deux.
OpenID et SAML2 sont tous deux basés sur le même concept d'identité fédérée. Voici quelques unes des différences entre eux ..
- SAML2 prend en charge la déconnexion unique - mais pas OpenID
- Les fournisseurs de services SAML2 sont associés aux fournisseurs d'identité SAML2, mais les parties qui s'appuient sur OpenID ne sont pas associés à des fournisseurs OpenID. OpenID a un protocole de découverte qui découvre de manière dynamique le fournisseur OpenID correspondant, une fois qu'un OpenID est donné. SAML a un protocole de découverte basé sur le service de découverte de fournisseur d'identité Protocole.
- Avec SAML2, l'utilisateur est couplé au IdP SAML2 - votre identifiant SAML2 n'est valide que pour l'IdP SAML2 qui l'a émis. Mais avec OpenID, vous possédez votre identifiant et vous pouvez le mapper à n’importe quel fournisseur OpenID de votre choix.
- SAML2 a différentes liaisons alors que la seule liaison avec OpenID est HTTP
- SAML2 peut être initié par le fournisseur de service (SP) ou par le fournisseur d'identité (IdP). Mais OpenID toujours SP lancé.
- SAML 2 est basé sur XML, contrairement à OpenID.
- La plupart des applications développées au cours des 3 dernières années ne prenaient en charge que OpenID Connect.
- 92% des demandes d'authentification 8B + transmises par Microsoft Azure AD en mai 2018 provenaient d'applications compatibles OpenID Connect.
Mettant de côté les détails techniques, étant assez en retard pour la fête, je comprends que la plus grande différence entre SAML et les autres standards d'authentification (y compris OpenID) est que
SAML requiert que le fournisseur d'identité (IDP) et le fournisseur de services (SP) se connaissent bien, pré-configuré, statique authentification et autorisation. OpenId (+ Connect) n'a pas une telle exigence.
Ceci est important pour les IDP qui souhaitent avoir le contrôle total sur les personnes qui accèdent aux données. Une partie de la norme consiste à configurer ce qui est fourni à des SP spécifiques.
Par exemple, une banque peut ne pas souhaiter que ses utilisateurs aient accès à des services autres que ceux prédéfinis (en raison de réglementations ou d'autres règles de sécurité strictes).
Cela ne signifie pas qu'un IDP OpenId ne peut pas appliquer une telle restriction. Un implémenteur OpenID peut contrôler l'accès, mais ce n'est pas le but d'OpenID.
Outre la différence prédéfinie, stricte, statique, de contrôle d'accès, conceptuellement (non techniquement), OpenID Connect et SAML sont similaires.
En bout de ligne, si vous êtes un fournisseur de services, vous devez répondre aux besoins de vos clients:
- Si votre client est un utilisateur final individuel (en utilisant son identifiant Google par exemple), oubliez SAML. Utilisez OpenID Connect.
- Si votre client est une banque qui souhaite que ses employés utilisent votre service et exportent uniquement la liste statique de données qu’il leur fournira, la banque voudra probablement que vous preniez en charge SAML. La banque pourrait avoir une implémentation OpenID avec une restriction client, ce qui sera votre jour de chance :)
@Prabath: OpenID prend en charge l'authentification unique.
Selon la question: OpenID permet l'authentification de l'utilisateur via des fournisseurs d'identité centralisés (IdP) sur plusieurs sites Web de confiance ou des parties en confiance. Lorsqu'un utilisateur est authentifié, il peut se déplacer librement entre plusieurs sites Web activés pour OpenID sans ressaisir ses informations d'identification.
SAML est une norme ouverte du secteur basée sur XML pour l'authentification d'utilisateur et les informations d'autorisation (assertions de sécurité) entre les fournisseurs de services et les consommateurs.
SAML et OpenID peuvent tous deux jouer le rôle de fournisseur d’identité (IdP abrégé), c’est-à-dire un protocole d’authentification décentralisé (identité de connexion unique).
Le S ecurity A ssertion M arkup L anguage (SAML) est un ensemble de profils pour l'échange de données d'authentification et d'autorisation entre domaines de sécurité. Dans le modèle de domaine SAML, un fournisseur d'identité est un type spécial d'autorité d'authentification. Plus précisément, un fournisseur d'identité SAML est une entité système qui émet des assertions d'authentification conjointement avec un profil d'authentification unique de SAML. Une partie de confiance qui utilise ces assertions d’authentification est appelée fournisseur de services SAML. La source
O pen ID _ {C onnect (OIDC) est une couche d'authentification au-dessus de OAuth 2.0, un cadre d'autorisation . Le standard est contrôlé par OpenID Foundation. OAuth est un protocole d'autorisation plutôt qu'un protocole d'authentification et OpenID spécifiquement conçu comme un protocole d'authentification. OIDC utilise de simples jetons Web JSON (JWT), ils sont plus faciles à utiliser par JavaScript.
Scénario de cas d'utilisation:
Utilisez OAuth si vos utilisateurs peuvent simplement vouloir se connecter avec Facebook ou Twitter. Utilisez OpenID si vos utilisateurs sont des hommes qui exploitent leurs propres fournisseurs OpenID, car ils "ne veulent pas que quiconque possède leur identité".