Quelle est la différence entre OpenID et SAML?

Quelle est la différence entre OpenID et SAML?

    OpenID 2.0 original 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 repose sur une confiance explicite entre votre site et le fournisseur d’identité. Il est donc plutôt rare d’accepter des informations d’identification à partir d’un site inconnu.

    Les identités OpenID sont faciles à trouver sur le net. En tant que développeur, vous pourriez alors 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 serait contraire au concept OpenID général.

    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 firebase database? 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 adresse e-mail) ne peut pas être fiable!

    D’un autre côté, 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 le courrier électronique. Cela signifie que vous avez tendance à croire que le fournisseur d’ID a en quelque sorte validé toutes les informations et que vous pouvez lui faire confiance 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, développée 08-2018)

    Cette réponse date de 2011 et OpenID représentait à l’époque 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 ).

    Pour quiconque lit ceci aujourd’hui – OpenID Connect n’est pas le même OpenID auquel la réponse d’origine fait référence , il s’agit plutôt d’un ensemble d’extensions à OAuth2.0.

    Bien que cette réponse puisse éclairer le sharepoint vue conceptuel, une version très concise pour ceux qui viennent avec un arrière-plan OAuth2.0 est que OpenID Connect est en fait OAuth2.0 mais ajoute un moyen standard d’ interroger les informations utilisateur , après le jeton d’access. est disponible.

    Se référant à la question initiale – 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 fichiers XML signés, l’application valide la signature elle-même et le certificate qu’elle présente. Les informations utilisateur sont incluses, entre autres, dans un jeton SAML.

    • OAuth2 construit la relation de confiance sur un appel HTTP direct de l’application à l’identité. La demande contient le jeton d’access (obtenu par l’application lors du stream de protocole) et la réponse contient les informations sur l’utilisateur.

    • OpenID Connect élargit 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, access_token , le même un OAuth2.0 et le nouveau, id_token qui est un jeton JWT , signé par le fournisseur d’identité. L’application peut utiliser le jeton d’identification pour établir une session locale, en fonction des revendications incluses dans le jeton JWT, mais le jeton d’identification ne peut pas être utilisé pour interroger d’autres services. Ces appels vers des services tiers doivent toujours utiliser le jeton d’access. Vous pouvez penser à OpenID Connect comme un hybride entre SAML2 (jeton signé) et OAuth2 (jeton d’access), car OpenID Connect implique 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 utilisant OpenID ne sont pas associées aux fournisseurs OpenID. OpenID a un protocole de découverte qui découvre dynamicment le fournisseur OpenID correspondant, une fois qu’un OpenID est donné. SAML a un protocole de découverte basé sur le protocole de service de découverte d’Identity Provider.
    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 souhaité.
    4. SAML2 a différentes liaisons alors que la seule liaison OpenID est HTTP
    5. SAML2 peut être initié par un fournisseur de services (SP) ou un fournisseur d’identité (IdP). Mais OpenID toujours SP initié.
    6. SAML 2 est basé sur XML alors qu’OpenID ne l’est pas.
    7. La plupart des applications développées au cours des 3 dernières années ne supportaient que OpenID Connect.
    8. 92% des demandes d’authentification 8B + Microsoft Azure AD remises en mai 2018 provenaient d’applications compatibles OpenID Connect.

    Mettre de côté les détails techniques, étant assez tard pour la fête, ce que je comprends, la plus grande différence entre SAML et les autres normes d’authentification (y compris OpenID) est que

    SAML exige que le fournisseur d’identité (IDP) et le fournisseur de services (SP) se connaissent mutuellement avant l’ authentification et l’autorisation statiques préconfigurées . OpenId (+ Connect) n’a pas cette exigence.

    Ceci est important pour les déplacés internes qui souhaitent avoir un contrôle total sur l’access 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 services prédéfinis (en raison de réglementations ou d’autres règles de sécurité ssortingctes).

    Cela ne signifie pas qu’un IDI OpenId, ne peut pas appliquer une telle ressortingction. Un implémenteur OpenID peut contrôler l’access, mais ce n’est pas le but d’OpenID.

    Outre la différence de contrôle d’access prédéfinie, ssortingcte et statique, conceptuellement (et non techniquement), OpenID Connect et SAML sont similaires.

    En bout de ligne, si vous êtes un fournisseur de services, vous devez prendre en charge les besoins de vos clients:

    1. Si votre client est un utilisateur individuel final (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 exportent uniquement une liste statique de données qu’il fournira à votre service, la banque voudra probablement que vous souteniez SAML. La banque peut avoir une implémentation OpenID avec une ressortingction client, ce qui sera votre jour de chance 🙂

    @Prabath: OpenID prend en charge la connexion 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 parties de confiance (RP). Lorsqu’un utilisateur est authentifié, il peut se déplacer librement entre plusieurs sites Web compatibles OpenID sans ressaisir ses informations d’identification.

    SAML est un standard ouvert de l’indussortinge basé sur XML pour l’authentification des utilisateurs Exchange et les informations d’autorisation (assertions de sécurité) entre les fournisseurs de services et les consommateurs.