SAML vs. OAuth: Which One Should I Use?

Als Teil des Projekts PicketLink (http://www.picketlink.org ) werden mir Fragen zu verschiedenen Aspekten von Sicherheit, Vertrauen und Identitätsmanagement gestellt.

Eine der primären Fragen, die mir gestellt werden, ist – „Was ist der Unterschied zwischen SAML und OAuth?“. Ich hoffe, ich kann in diesem Artikel meine Gedanken zu diesem wichtigen Thema darlegen. Ich werde auch versuchen, verschiedene Anwendungsfälle aufzuzeigen, in denen jeder von beiden bevorzugt wird.

Was ist der große Unterschied zwischen SAML und OAuth?

Informativ in meinen eigenen Worten:

SAML (Security Assertion Markup Language) ist ein Dachstandard, der Profile, Bindungen und Konstrukte umfasst, um Single Sign On (SSO), Federation und Identity Management zu erreichen.

OAuth (Open Authorization) ist ein Standard für die Autorisierung von Ressourcen. Es befasst sich nicht mit Authentifizierung.

Für formale Definitionen:

Laut Wikipedia-Seite zu SAML:

Security Assertion Markup Language ist ein XML-basiertes, offenes Standard-Datenformat für den Austausch von Authentifizierungs- und Autorisierungsdaten zwischen Parteien, insbesondere zwischen einem Identitätsanbieter und einem Dienstanbieter.

Nach Angaben von OAuth.net

Ein offenes Protokoll, um eine sichere Autorisierung in einer einfachen und standardisierten Methode von Web-, Mobil- und Desktop-Anwendungen zu ermöglichen.

Was sind die weiteren Unterschiede?

1. Token- oder Nachrichtenformat<

SAML beschäftigt sich mit XML als Datenkonstrukt oder Token-Format.

OAuth-Tokens können binär, JSON oder SAML sein, wie in OAuth Bearer Tokens erklärt.

2. Transport

SAML hat Bindungen, die HTTP verwenden, wie z.B. HTTP POST Binding, HTTP REDIRECT Binding usw.

Aber es gibt keine Einschränkung für das Transportformat. Sie können SOAP oder JMS oder jeden beliebigen Transport verwenden, um SAML-Token oder Nachrichten zu senden.

OAuth verwendet ausschließlich HTTP.

3. Anwendungsbereich

Auch wenn SAML für eine offene Anwendung konzipiert wurde, wird es typischerweise in Enterprise-SSO-Szenarien eingesetzt –

  • innerhalb eines Unternehmens oder
  • Unternehmen zu Partner oder
  • Unternehmen zu Cloud-Szenarien.

OAuth wurde für den Einsatz mit Anwendungen im Internet konzipiert, primär für die delegierte Autorisierung von Internet-Ressourcen. OAuth ist für Internet Scale konzipiert.

Welche Versionen der Standards sollte ich verwenden?

SAML v2.0 und OAuth v2.0 sind die neuesten Versionen der Standards.

Wann sollte ich welche verwenden?

  • Wenn Ihr Anwendungsfall SSO beinhaltet (wenn mindestens ein Akteur oder Teilnehmer ein Unternehmen ist), dann verwenden Sie SAML.
  • Wenn Ihr Anwendungsfall den (temporären oder permanenten) Zugriff auf Ressourcen (wie Konten, Bilder, Dateien usw.) beinhaltet, dann verwenden Sie OAuth.
  • Wenn Sie Ihrem Portal Zugriff auf eine Partner- oder Kundenanwendung gewähren müssen, dann verwenden Sie SAML.
  • Wenn Ihr Anwendungsfall eine zentralisierte Identitätsquelle erfordert, dann verwenden Sie SAML (Identity Provider).
  • Wenn Ihr Anwendungsfall mobile Geräte einbezieht, dann ist OAuth2 mit einer Form von Bearer Tokens angemessen.

Ich möchte sowohl SAML als auch OAuth verwenden. Kann ich das?

Sie können SAML für die Authentifizierung verwenden. Sobald Sie ein SAML-Token/Assertion haben, können Sie dieses als OAuth-Token im HTTP-Bearer-Header verwenden, um auf geschützte Ressourcen zuzugreifen.

Kürzlich hatten wir eine Anforderung aus der PicketLink-Community, die in diese Richtung ging.

https://docs.jboss.org/author/display/PLINK/REST+Service+to+convert+SAML+Tokens+Into+OAuth+Tokens

Was ist die Alternative zu SAML-XML-Token in der OAuth-Welt?

Schauen Sie sich JSON Web Token (JWT) an: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/

JWT Bearer Tokens können mit OAuth2 verwendet werden.

Die OpenID Foundation arbeitet mit OpenID Connect. http://openid.net/specs/openid-connect-basic-1_0-22.html

OpenID Connect ist eine Identitätsschicht über OAuth2, die Profilinformationen von Benutzern von den Autorisierungsservern bereitstellen kann (basierend auf der durchgeführten Authentifizierung).

  • PicketLink Open Source Projekt auf http://www.picketlink.org
  • OAuth Theorie auf der PicketLink Seite.
  • IETF Web Authorization Working Group (http://datatracker.ietf.org/wg/oauth/charter/)
  • IETF OAuth2 (http://datatracker.ietf.org/doc/rfc6749/)
  • Google OAuth Dokument (https://developers.google.com/accounts/docs/OAuth2)
  • Microsoft Windows Live OAuth2-Dokument (http://msdn.microsoft.com/en-us/library/live/hh243647.aspx)
  • Amazon Web Services und SAML http://aws.typepad.com/aws/2013/11/aws-identity-and-access-management-using-saml.html
  • Salesforce SAML. https://help.salesforce.com/apex/HTViewHelpDoc?id=sso_saml.htm&language=en
  • Google Apps SAML. https://developers.google.com/google-apps/sso/saml_reference_implementation
  • OpenID Connect http://openid.net/specs/openid-connect-basic-1_0-22.html

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.