Quelle est la différence entre OpenID et SAML?

Quelle est la différence entre OpenID et SAML?

OpenID 2.0 original contre SAML

Ce sont deux protocoles d'authentification différents et ils diffèrent au niveau technique.

De loin, les différences commencent lorsque les utilisateurs lancent l'authentification. Avec OpenID, la connexion d'un 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 les informations d'identification d'un site inconnu.

Les identités OpenID sont faciles à parcourir sur le net. En tant que développeur, vous pouvez simplement accepter des utilisateurs provenant de fournisseurs OpenID très différents. D'un autre côté, un fournisseur SAML doit généralement être codé à l'avance et vous fédérez votre application avec uniquement des 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 d'OpenID.

Avec OpenID, vous acceptez les identités provenant de serveurs arbitraires. Quelqu'un prétend l'ê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 le reconnaissant lorsque l'utilisateur visite à nouveau votre site. Notez que toute autre information sur l'utilisateur (y compris son nom ou son e-mail) n'est pas fiable!

D'autre part, s'il existe une confiance explicite entre votre application et le fournisseur d'identifiant SAML, vous pouvez obtenir des informations complètes sur l'utilisateur, y compris le nom et l'adresse e-mail, et ces informations peuvent être approuvées, simplement en raison de la relation d'approbation. Cela signifie que vous avez tendance à croire que le fournisseur d'identifiant a validé d'une manière ou d'une autre toutes les informations et que vous pouvez lui faire confiance au niveau de l'application. Si les utilisateurs sont livrés avec des jetons SAML émis par un fournisseur inconnu, votre application refuse simplement l'authentification.

OpenID Connect vs SAML

(section ajoutée 07-2017, étendue 08-2018)

Cette réponse date 2011 et à ce moment - là pour se OpenID OpenID 2.0 . Plus tard, quelque part en 2012, OAuth2.0 a été publié et en 2014, OpenID Connect (une chronologie plus détaillée ici ).

À tous ceux qui lisent ceci de nos jours - OpenID Connect n'est pas le même OpenID auquel la réponse originale se réfère , mais plutôt un ensemble d'extensions à OAuth2.0.

Bien que cette réponse peut faire la lumière du point de vue conceptuel, une version très concise pour quelqu'un qui sont familiers avec OAuth2.0 est qu'OpenID Connect est en fait OAuth2.0 mais il ajoute un moyen standard de l' interrogation informations de l' utilisateur , après le jeton d'accès est disponible.

En référence à la question d'origine - quelle est la principale différence entre OpenID Connect (OAuth2.0) et SAML est la façon dont la relation de confiance est 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 pendant le flux de protocole) et la réponse contient les informations sur l'utilisateur.

• OpenID Connect étend encore cela 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_tokenmême problème OAuth2.0 et le nouveau, id_tokenqui est un jeton JWT , signé par le fournisseur d'identité. L'application peut utiliser id_tokenpour établir une session locale, sur la base des revendications incluses dans le jeton JWT, mais id_token ne peut pas être utilisée pour interroger davantage d'autres services, de tels appels à des services tiers doivent toujours utiliser leaccess_token. Vous pouvez alors considérer OpenID Connect comme un hybride entre SAML2 (jeton signé) et OAuth2 (jeton d'accès), car OpenID Connect implique simplement 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.

1. SAML2 prend en charge la déconnexion unique, mais OpenID ne le fait pas
2. Les fournisseurs de services SAML2 sont couplés aux fournisseurs d'identité SAML2, mais les parties de confiance OpenID ne sont pas associées aux fournisseurs OpenID. OpenID a un protocole de découverte qui découvre dynamiquement le fournisseur OpenID correspondant, une fois qu'un OpenID est donné. SAML dispose d'un protocole de découverte basé sur le protocole de service de découverte de fournisseur d'identité.
3. Avec SAML2, l'utilisateur est couplé à l'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.
4. SAML2 a des liaisons différentes tandis que la seule liaison qu'OpenID a est HTTP
5. SAML2 peut être lancé par le fournisseur de services (SP) ou par le fournisseur d'identité (IdP). Mais OpenID a toujours été lancé par SP.
6. SAML 2 est basé sur XML alors qu'OpenID ne l'est pas.
7. La plupart des applications développées ces 3 dernières années ne supportaient que OpenID Connect.
8. 92% des demandes d'authentification 8B + envoyées par Microsoft Azure AD en mai 2018 provenaient d'applications compatibles OpenID Connect.

Mis à part les détails techniques, étant assez tard pour la fête, ce que je comprends que la plus grande différence entre SAML et les autres standards d'authentification (notamment OpenID) est que

SAML exige que le fournisseur d'identité (IDP) et le fournisseur de services (SP) se connaissent à l'avance, pré-configurés , authentification et autorisation statiques . OpenId (+ Connect) n'a pas une telle exigence.

Ceci est important pour les PDI qui veulent un contrôle total sur qui accède 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 accèdent à des services à l'exception de certains 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 développeur OpenID peut contrôler l'accès, mais ce n'est pas le but d'OpenID.

Outre la différence de contrôle d'accès prédéfinie, stricte et statique, sur le plan conceptuel (pas technique), OpenID Connect et SAML sont similaires.

En fin de compte, si vous êtes un SP, vous devez prendre en charge ce dont vos clients ont besoin:

1. Si votre client est un utilisateur final individuel (en utilisant son identifiant Google par exemple), oubliez SAML. Utilisez OpenID Connect.
2. Si votre client est une banque qui souhaite que ses employés utilisent votre service et n'exportent que la liste statique des données qu'elle fournira à votre service, la banque voudra probablement que vous souteniez SAML. La banque peut avoir une implémentation OpenID avec restriction client, ce qui sera votre jour de chance :)

SAML et OpenID peuvent tous deux agir en tant que fournisseur d'identité (IdP abrégé), c'est-à-dire protocole d'authentification décentralisé (identité de connexion unique).

Le S écurité A ssertion M arkup L angue ( SAML ) est un ensemble de profils pour l' échange de données d'authentification et d' autorisation dans les domaines de la 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 SSO de SAML. Une partie de confiance qui utilise ces assertions d'authentification est appelée un fournisseur de services SAML. La source

O pen ID C onnect ( OIDC ) est une couche d'authentification au-dessus d'OAuth 2.0, un cadre d'autorisation. Le standard est contrôlé par OpenID Foundation. OAuth est pour le protocole d'autorisation, plutôt qu'un protocole d'authentification et OpenID spécifiquement conçu comme protocole d'authentification. OIDC utilise de simples jetons Web JSON (JWT), ils sont plus faciles à consommer par JavaScript.

Scénario de cas d'utilisation:

Utilisez OAuth si vos utilisateurs souhaitent simplement se connecter avec Facebook ou Twitter. Utilisez OpenID si vos utilisateurs sont des cousins ​​qui exécutent leurs propres fournisseurs OpenID parce qu'ils «ne veulent pas que quelqu'un d'autre possède leur identité».

La source