SAML vs. OAuth2.0 vs. OpenID Connect (OIDC)

SAML (Security Assertion Markup Language), OAuth (Open Authorization) und OpenID Connect (OIDC) sind Protokolle, die zur Bereitstellung von Identitäts- und Zugriffsmanagementlösungen (IAM) verwendet werden.

SAML wird in erster Linie für webbasiertes Single Sign-On (SSO) verwendet und ermöglicht es Benutzern, sich an einem Standort zu authentifizieren und dann auf mehrere andere Standorte zuzugreifen, ohne ihre Anmeldedaten erneut eingeben zu müssen. SAML basiert auf dem Austausch von digital signierten XML-Dokumenten, um Authentifizierungsinformationen zwischen dem Identitätsanbieter (IdP) und dem Dienstanbieter (SP) zu übermitteln.

OAuth ist ein Standard, der es Benutzern ermöglicht, Anwendungen von Drittanbietern Zugriff auf ihre Ressourcen zu gewähren (z. B. die Daten eines Benutzers auf einer Social-Media-Website), ohne ihre Anmeldedaten weitergeben zu müssen. Dies geschieht, indem der Benutzer die Anwendung autorisiert, in seinem Namen zu handeln, indem er ihr ein Zugriffstoken ausstellt, das die Anwendung dann für den Zugriff auf die geschützten Ressourcen verwenden kann.

OpenID Connect ist eine Erweiterung von OAuth 2.0, die das OAuth-Protokoll um eine Identitätsschicht ergänzt. Es ermöglicht Benutzern, sich mit ihren Anmeldedaten beim Identitätsanbieter (IdP) zu authentifizieren, und autorisiert dann Anwendungen von Drittanbietern für den Zugriff auf ihre Identitätsinformationen (z. B. ihren Namen und ihre E-Mail-Adresse) sowie auf andere Ressourcen, für die der Benutzer eine Zugriffsberechtigung erteilt hat.

Zusammenfassend lässt sich sagen, dass SAML für webbasiertes SSO, OAuth für die Zugriffsdelegation und OpenID Connect für die Authentifizierung (Identität) und Zugriffsdelegation verwendet wird.

Details

SAML basiert auf dem Austausch von digital signierten XML-Nachrichten zwischen dem Identitätsanbieter (IdP) und dem Dienstanbieter (SP). Der Prozess beginnt, wenn der Benutzer versucht, auf eine Ressource des SP zuzugreifen. Der SP sendet dann eine Authentifizierungsanfrage an den IdP in Form einer SAML AuthnRequest. Der IdP authentifiziert den Benutzer und erstellt eine digital signierte SAML-Assertion, die die Authentifizierungsinformationen des Benutzers enthält, z. B. seinen Benutzernamen und seine Attribute. Der IdP sendet dann die Assertion an den SP, der die Signatur prüft und dem Benutzer den Zugriff auf die Ressource gewährt.

OAuth ist ein Rahmenwerk für die Zugriffsdelegation, kein Authentifizierungsprotokoll, es liefert keine Informationen über die Identität des Benutzers. Der Prozess beginnt, wenn der Benutzer einer Drittanbieteranwendung die Erlaubnis erteilt, auf seine Ressourcen auf einem Ressourcenserver (RS) zuzugreifen. Der Autorisierungsserver (AS) generiert ein Zugriffstoken und sendet es an die Anwendung. Die Anwendung kann dann dieses Token verwenden, um auf die Ressourcen des Benutzers auf dem RS zuzugreifen. Das Token ist eine zufällige Zeichenfolge, die die der Anwendung erteilte Berechtigung darstellt und auch Angaben über den Benutzer und den Umfang der Berechtigung enthalten kann.

OpenID Connect ist eine Erweiterung von OAuth 2.0, die das Protokoll um eine Identitätsschicht ergänzt. Sie ermöglicht es Benutzern, sich mit ihren Anmeldedaten beim Identitätsanbieter (IdP) zu authentifizieren, und autorisiert dann Anwendungen von Drittanbietern, auf ihre Identitätsinformationen (wie Name und E-Mail-Adresse) sowie auf andere Ressourcen zuzugreifen, für die der Benutzer eine Zugriffsberechtigung erteilt hat. Diese Identitätsinformationen werden in Form eines JSON-Web-Tokens (JWT), auch ID-Token genannt, übergeben.

OAuth und OpenID Connect verwenden beide den gleichen Mechanismus von Zugriffstoken für den Zugriff auf Benutzerressourcen und können beide JWT als Format für das Token verwenden. OAuth konzentriert sich jedoch auf die Zugriffsdelegation und OpenID Connect auf die Authentifizierung und Zugriffsdelegation.

Erfahren Sie alles über SAML in unserem Blog Post.

Erfahren Sie alles über OAuth2.0 in unserem Blog Post.

Erfahren Sie alles über OpenID Connect in unserem Blog Post.

Können diese Protokolle im Hintergrund laufen?

SAML, OAuth und OpenID Connect sind alles Protokolle, die typischerweise in webbasierten Szenarien verwendet werden, in denen ein Benutzer mit einer Webanwendung in einem Browser interagiert. Sie werden in der Regel nicht zur Ausführung von Hintergrundaufgaben oder -diensten verwendet.

SAML wird hauptsächlich für das webbasierte Single Sign-On (SSO) verwendet, bei dem sich ein Benutzer an einer Website authentifiziert und dann auf mehrere andere Websites zugreifen kann, ohne seine Anmeldedaten erneut eingeben zu müssen. Der SAML-Nachrichtenaustausch findet im Rahmen der Interaktion des Benutzers mit der Webanwendung statt.

OAuth wird hauptsächlich verwendet, um Anwendungen von Drittanbietern Zugriff auf die Ressourcen eines Benutzers zu gewähren (z. B. Daten auf einer Social-Media-Website), ohne die Anmeldedaten des Benutzers weiterzugeben. Es beruht darauf, dass der Benutzer der Anwendung die Erlaubnis erteilt, was in der Regel durch einen interaktiven Prozess in einem Webbrowser geschieht.

OpenID Connect ist eine Erweiterung von OAuth 2.0, die dem Protokoll eine Identitätsschicht hinzufügt und ebenfalls für interaktive webbasierte Szenarien verwendet wird.

Es ist jedoch möglich, Hintergrundaufgaben auszuführen, die diese Protokolle verwenden, sofern der Benutzer dies ausdrücklich erlaubt, was jedoch nicht standardmäßig der Fall ist.

Sie können diese Protokolle auch mit anderen Technologien wie Bearer Token und Refresh Token kombinieren, damit sich Hintergrundaufgaben authentifizieren und bei Bedarf neue Token erhalten.

Was ist JWT?

JSON Web Token (JWT) ist ein Standard zur sicheren Erstellung und Darstellung von Ansprüchen zwischen zwei Parteien. Er wird häufig für die Authentifizierung und Autorisierung in Webanwendungen und APIs verwendet. JWT ist ein JSON-Objekt, das als Zeichenkette kodiert ist und in der Regel eine Reihe von Ansprüchen, d. h. Aussagen über eine Entität (in der Regel den Benutzer) und zusätzliche Metadaten enthält.

Hier sind einige der wichtigsten Merkmale von JWT:

• Kompakt: JWT ist ein kompaktes Format, das über eine URL, einen POST-Parameter oder innerhalb eines HTTP-Headers gesendet werden kann. Dadurch lässt es sich leicht über das Netzwerk übertragen.
• In sich geschlossen: JWT enthält alle notwendigen Informationen über den Benutzer, so dass der Server die Datenbank nicht abfragen muss, um das Token zu validieren. Dies kann die Leistung der Anwendung verbessern.
• Manipulationssicher: JWT ist kryptografisch signiert, was bedeutet, dass den Angaben in einem JWT nur dann vertraut werden kann, wenn sie von der Partei signiert sind, die für die Erstellung des Tokens verantwortlich ist. Dies bedeutet, dass das Token während der Übertragung nicht manipuliert werden kann, ohne dass die Signatur ungültig wird.

Aufbau

JWT hat eine spezifische Struktur, die aus drei Teilen besteht: Header, Payload und Signatur, die durch das Zeichen ‚.‘ getrennt sind. Der Header besteht in der Regel aus zwei Teilen: dem Typ des Tokens, d. h. JWT, und dem verwendeten Signieralgorithmus, z. B. HMAC SHA256 oder RSA. Die Nutzdaten enthalten die Claims, d. h. Aussagen über eine Entität, und die Signatur wird verwendet, um zu überprüfen, ob der Absender des JWT derjenige ist, für den er sich ausgibt, und um sicherzustellen, dass die Nachricht unterwegs nicht verändert wurde.

Anwendungsfälle

JWT werden verwendet, um die Authentifizierung und Autorisierung in Webanwendungen und APIs zu sichern. Sie können verwendet werden, um den Benutzer zu authentifizieren und Informationen über den Benutzer und seine Rolle im System zu übermitteln. Diese Informationen können verwendet werden, um zu überprüfen, ob der Benutzer berechtigt ist, bestimmte Aktionen durchzuführen. JWT können auch als Sitzungs-Token verwendet werden, d. h. sie können dazu verwendet werden, die Sitzung des Benutzers zu verfolgen und sie bei Bedarf jederzeit zu widerrufen.

Weitere Eigenschaften

JWT können auf der Serverseite erstellt und an den Client gesendet werden. Der Client kann sie dann in jede Anfrage an den Server einfügen, der Server kann dann das JWT validieren und die darin enthaltenen Angaben verwenden, um den Benutzer zu authentifizieren und die Anfrage zu autorisieren.

JWT sind außerdem zustandslos, was bedeutet, dass der Server keinen Sitzungsstatus aufrechterhalten muss, was in verteilten Systemen oder Microservices-Architekturen von Nutzen sein kann.

JWT haben auch einige Sicherheitsaspekte: JWT sollten mit einem privaten Schlüssel signiert und mit dem entsprechenden öffentlichen Schlüssel validiert werden, und der Signieralgorithmus sollte entsprechend den Sicherheitsanforderungen gewählt werden. JWT sollten auch über eine sichere Transportschicht wie HTTPS gesendet werden, um Abhör- und Man-in-the-Middle-Angriffe zu verhindern.