Quelles sont les différences entre les jetons Web JSON, SAML et OAuth 2?
Quelles sont les différences entre les jetons Web JSON, SAML et OAuth 2. Veuillez fournir quelques pointeurs et un aperçu de haut niveau de leurs fonctions.
Plus précisément, pourquoi utiliser SAML sur des jetons Web JSON ou vice versa? Faut-il avoir OAuth 2 pour utiliser les jetons Web JSON/SAML? Ou les jetons Web JSON/SAML peuvent-ils être utilisés indépendamment?
SAML et OAuth 2 sont des protocoles utilisés pour l'authentification/autorisation. JSON Web Tokens (JWT) est une spécification pour un jeton qui peut être utilisé dans de nombreuses applications ou protocoles - il arrive que l'OpenID Connect ( Le protocole OIDC) utilise le JWT. SAML définit également son propre jeton: SAML Assertion; tout comme OAuth 2: jeton d'accès. Les jetons utilisés par ces protocoles indiquent que vous avez été authentifié/autorisé et transmettent des informations sur vous ou la session.
+----------+----------------+-------------------------------+
| Protocol | Token | Technologies | Design Pattern |
+==========+================+==============+================+
| SAML | SAML Assertion | SOAP, XML | Facade |
+----------+----------------+--------------+----------------+
| OAuth 2 | Access Token | | Proxy |
+----------+----------------+--------------+----------------+
| OIDC | Access Token, | REST, JSON | Decorator |
| | ID Token (JWT) | | |
+----------+----------------+--------------+----------------+
Les modèles de conception de logiciels associés à chacun des protocoles du tableau ci-dessus résument en un mot ce que ces protocoles étaient censés accomplir.
SAML . Le modèle de façade fournit une interface unifiée à un ensemble d'interfaces dans un sous-système. SAML est le système d'identité fédéré original, inventé par les universités pour permettre aux étudiants d'accéder à d'autres bibliothèques universitaires, mais chaque université maintient son propre système d'identité des étudiants. De facto standard dans la plupart des environnements d'entreprise. Construit autour de XML et SOAP.
OAuth 2. Le proxy, un peu comme son nom l'indique, permet aux clients d'accéder à vos informations comme s'ils étaient un proxy pour vous.
OIDC . Étend OAuth 2 en ajoutant un ID utilisateur et des informations utilisateur au protocole. Souvent considéré comme une version moderne de SAML. Utilisation répandue dans l'espace consommateur - presque tous les sites de médias sociaux prennent en charge OIDC. Construit autour de JSON et REPOS.
Espérons que cela démêle un peu vos questions. Vous ne pouvez pas vraiment comparer SAML (protocole) avec JWT (jeton), mais vous pouvez comparer SAML avec OIDC. Vous pouvez cependant comparer une assertion SAML avec un JWT OIDC. La spécification OAuth 2 ne spécifie pas la structure sous-jacente de ses jetons. Vous pourriez également trouver intéressant qu'OIDC puisse consommer l'assertion SAML ainsi que son propre JWT.
Le consensus est que l'OIDC finira par remplacer SAML, mais SAML existe depuis 2005 et est très mature - un trait important dans les environnements d'entreprise. Même si OIDC est relativement nouveau (2014), les solutions d'authentification de nos jours (2018) devraient le prendre en charge. SAML a été conçu à une époque où les navigateurs Web dominaient et a un peu de mal avec les applications Web mobiles ou modernes. OIDC, d'autre part, prend en charge les technologies modernes telles que REST et JSON, ce qui le rend beaucoup plus accessible depuis les applications de nos jours.
Cependant, OAuth 2, OIDC et SAML ne spécifient pas réellement comment l'authentification et l'autorisation sont effectuées de la façon dont ces deux termes sont traditionnellement définis.
Lorsque vous entendez l'authentification, vous pensez à un identifiant/mot de passe, à une empreinte digitale ou à un mot de passe envoyé à votre téléphone - aucun de ces protocoles ne couvre ces spécificités, plutôt que l'authentification est déléguée au fournisseur d'identité (IdP). Ces protocoles spécifient comment vous devez être redirigé vers un IdP pour vous authentifier et, en cas de succès, comment les jetons/assertions sont renvoyés.
L '"autorisation" OAuth 2 consiste à obtenir le consentement de l'utilisateur , c'est-à-dire s'il faut donner à un service un accès à vos informations/données - cela ne signifie pas l'autorisation dans le contrôle d'accès sens. OIDC, tout comme OAuth 2 prend également en charge un moyen d'obtenir le consentement de l'utilisateur. Bien que SAML prenne également en charge le consentement de l'utilisateur, il n'est généralement pas utilisé dans un environnement d'entreprise/intranet.
L'autorisation (se référant à la signification de contrôle d'accès plus traditionnelle) n'est pas non plus dans les spécifications OAuth 2, OIDC et SAML, mais elles permettent aux jetons de contenir des revendications telles que l'appartenance d'un utilisateur à un groupe d'administrateurs , que les services clients peuvent interpréter comme bon leur semble.
OAuth 2, OIDC et SAML sont d'excellents facilitateurs pour différents schémas d'authentification et d'autorisation (contrôle d'accès), mais ne spécifient pas réellement les mécanismes sous-jacents réels.
MISE À JOUR 9/5/2018. Mis à jour pour 2018.
MISE À JOUR 26/04/2017. Correction d'une déclaration incorrecte sur SAML ne prenant pas en charge le consentement de l'utilisateur - c'est le cas, mais pas largement utilisé.
MISE À JOUR 2/22/2017. Clarifiez l'authentification, l'autorisation (contrôle d'accès) et le consentement de l'utilisateur en réponse au commentaire de l'utilisateur ci-dessous.