Deutsch

iam
oauth
openid-connect
saml
sso
jwt

Verstehen Sie IAM, OAuth, OpenID Connect, SAML, SSO und JWT in einem Artikel

Die Welt des Identity- und Access-Managements (IAM) kann überwältigend und verwirrend erscheinen. Aber keine Sorge - dieser Artikel wird die Grundlagen von ihnen aufschlüsseln, um Ihnen zu helfen, das größere Bild zu sehen und sich in diesem komplexen Bereich selbstbewusst zurechtzufinden.

Gao

Founder

11/23/2024

Verschwenden Sie keine Wochen mit Benutzerauthentifizierung

Bringen Sie sichere Apps schneller mit Logto auf den Markt. Integrieren Sie Benutzerauthentifizierung in Minuten und konzentrieren Sie sich auf Ihr Kernprodukt.

Jetzt starten

Das Gebiet des Identity- und Access-Managements (IAM) ist in den letzten Jahren immer komplexer geworden. Die ausgefallenen Begriffe wie OAuth, OpenID Connect (OIDC), SAML, SSO und JWT werden häufig verwendet, aber was bedeuten sie? Wie arbeiten sie zusammen? Lassen Sie uns diese Konzepte und Frameworks erkunden, um sie verständlicher und praktikabler zu machen.

Was ist IAM?

Identity- und Access-Management (IAM) ist ein weitreichendes Konzept, das die Verwaltung digitaler Identitäten und die Implementierung von Zugriffskontrollen umfasst. Die zuvor erwähnten Frameworks und Protokolle fallen unter IAM und adressieren jeweils spezifische Herausforderungen in diesem Bereich.

Im Wesentlichen geht es bei IAM um:

Identität: Eine digitale Darstellung eines Benutzers, Dienstes oder Geräts. Eine Identität umfasst typischerweise Attribute wie Name, E-Mail, Rollen usw., um die Entität zu beschreiben.
Zugriff: Die Fähigkeit, mit Ressourcen zu interagieren, Aktionen auszuführen oder Dienste zu nutzen. Der Zugriff definiert, welche Aktionen auf welchen Ressourcen ausgeführt werden können.

Im obigen Diagramm möchte ein Benutzer (Identität) eine GET-Anfrage an eine API (Ressource) stellen. Die Attribute des Benutzers - Name, E-Mail und Rolle - beschreiben die Identität.

Authentifizierung vs. Autorisierung

Authentifizierung und Autorisierung treten häufig zusammen in IAM-Diskussionen auf. Lassen Sie uns ihre Definitionen klären:

Authentifizierung: Der Prozess der Überprüfung des Besitzes einer Identität. Es beantwortet die Frage: „Welche Identität besitzt du?“
Autorisierung: Der Prozess der Bestimmung, welche Aktionen eine authentifizierte Identität auf einer Ressource ausführen kann. Es beantwortet die Frage: „Was kannst du tun?“

Im vorherigen Beispiel:

Bevor der Benutzer (Identität) irgendwelche Aktionen ausführen kann, muss er den Authentifizierungsprozess abschließen.
Nach der Authentifizierung muss das System bestimmen, ob der Benutzer eine GET-Anfrage (Aktion) an die API (Ressource) ausführen kann, d.h. den Autorisierungsprozess abschließen.

Mit diesem grundlegenden Wissen ausgestattet, lassen Sie uns die anderen Akronyme und Protokolle entmystifizieren.

OAuth

OAuth 2.0, allgemein als OAuth bezeichnet, ist ein Autorisierungsframework, das es einer Anwendung ermöglicht, auf geschützte Ressourcen einer anderen Anwendung zuzugreifen (typischerweise im Namen eines Benutzers).

Zum Beispiel, stellen Sie sich vor, Sie haben eine Webanwendung namens MyApp, die auf das Google Drive eines Benutzers zugreifen möchte. Anstatt den Benutzer zu bitten, seine Google Drive-Anmeldedaten zu teilen, kann MyApp OAuth 2.0 verwenden, um Google um Erlaubnis (Autorisierung) zu bitten, auf das Drive des Benutzers zuzugreifen.

Hier ist ein vereinfachtes Diagramm, das den OAuth-Ablauf veranschaulicht:

In diesem Ablauf:

MyApp ist der Client (Identität), der Zugriff auf Google Drive (Ressource) anfordert.
Der Benutzer (Ressourceneigentümer) gewährt MyApp die Erlaubnis in Schritt 6 und schließt damit den Autorisierungsprozess ab.

Ein Schlüsselelement in OAuth 2.0 ist das Access Token, das der Client verwendet, um die Autorisierung des Benutzers für den Zugriff auf Ressourcen nachzuweisen. Um tiefer einzutauchen, siehe Access Token.

OpenID Connect (OIDC)

OpenID Connect (OIDC) ist eine Authentifizierungsschicht, die auf OAuth 2.0 aufbaut. Es fügt speziell für die Authentifizierung vorgesehene Funktionen hinzu, wie ID Tokens und einen UserInfo-Endpunkt, wodurch es sowohl für Authentifizierung als auch Autorisierung geeignet ist.

Wenn wir den OAuth-Ablauf erneut betrachten, fügt OIDC ein ID Token hinzu. Dieses Token enthält Informationen über den authentifizierten Benutzer und ermöglicht es MyApp, die Identität des Benutzers zu überprüfen.

Beispiel: „Mit Google anmelden“

Lassen Sie uns das Beispiel wechseln. Wenn MyApp den Benutzern ermöglichen möchte, sich mit ihren Google-Konten anzumelden, liegt das Ziel eher bei der Authentifizierung als beim Ressourcenzugriff. In diesem Fall ist OIDC besser geeignet. So sieht der OIDC-Ablauf aus:

Wichtiger Unterschied: Zusätzlich zu einem Access Token liefert OIDC ein ID Token, mit dem MyApp den Benutzer authentifizieren kann, ohne zusätzliche Anfragen zu stellen.

OIDC teilt die Grants von OAuth 2.0 und stellt so die Kompatibilität und Konsistenz zwischen den beiden Frameworks sicher.

SAML

Security Assertion Markup Language (SAML) ist ein auf XML basierendes Framework zum Austausch von Authentifizierungs- und Autorisierungsdaten zwischen Parteien. SAML, das in den frühen 2000er Jahren eingeführt wurde, hat in Unternehmensumgebungen weite Verbreitung gefunden.

Wie vergleicht sich SAML mit OIDC?

SAML und OIDC sind funktional ähnlich, unterscheiden sich jedoch in ihren Implementierungsdetails:

SAML: Verwendet XML-basierte Assertions und gilt oft als komplizierter.
OIDC: Nutzt JSON und JWT, was es leichter und entwicklerfreundlicher macht.

Moderne Anwendungen bevorzugen oft OIDC aufgrund seiner Einfachheit und Flexibilität, aber SAML bleibt in Legacy-Systemen und Unternehmensanwendungen verbreitet.

Single Sign-on (SSO)

Single Sign-on (SSO) ist ein Authentifizierungsschema, das es Benutzern ermöglicht, mit einem einzigen Satz von Zugangsdaten auf mehrere Anwendungen und Dienste zuzugreifen. Anstatt sich einzeln bei jeder Anwendung anzumelden, loggt sich der Benutzer einmal ein und erhält Zugriff auf alle verbundenen Systeme.

Wie funktioniert SSO?

SSO basiert auf einem zentralen Identity Provider (IdP), um Benutzeridentitäten zu verwalten. Der IdP authentifiziert den Benutzer und bietet Dienste wie Authentifizierung und Autorisierung für verbundene Anwendungen an.

Der IdP kann Protokolle wie OIDC, OAuth 2.0, SAML oder andere verwenden, um diese Dienste bereitzustellen. Ein einzelner IdP kann mehrere Protokolle unterstützen, um die unterschiedlichen Bedürfnisse verschiedener Anwendungen zu erfüllen.

Beispiel für OIDC-basiertes SSO

Lassen Sie uns ein Beispiel für OIDC-basiertes SSO erkunden:

In diesem Ablauf meldet sich der Benutzer einmal beim IdP an und wird über mehrere Anwendungen hinweg (AppA und AppB) authentifiziert.

Enterprise SSO

Während SSO ein breit gefaßtes Konzept ist, könnte Ihnen auch der Begriff Enterprise SSO begegnen, der sich auf eine spezielle Art von SSO bezieht, die für Unternehmensumgebungen (typischerweise für Mitarbeiter und Partner) entwickelt wurde.

Wenn ein Kunde SSO für Ihre Anwendung anfordert, ist es wichtig, seine Bedürfnisse und die von ihm verwendeten Protokolle zu klären. In den meisten Fällen bedeutet dies, dass sie für bestimmte E-Mail-Domains möchten, dass Ihre Anwendung Benutzer zu ihrem IdP (der Enterprise SSO implementiert) für die Authentifizierung umleitet.

Beispiel: Hinzufügen eines Enterprise SSO Providers

Hier ist ein vereinfachtes Beispiel der Integration eines Enterprise SSO Anbieters (Banana) mit Ihrer Anwendung (MyApp):

JWT

JSON Web Token (JWT) ist ein offener Standard, definiert in RFC 7519, der eine sichere Kommunikation zwischen zwei Parteien ermöglicht. Es ist das Standardformat für ID-Tokens in OIDC und wird häufig für OAuth 2.0 Access Tokens verwendet.

Hier sind die wichtigsten Merkmale von JWT:

Kompakt: JWTs sind JSON-Objekte, die in einem kompakten Format kodiert sind, was sie leicht übertragbar und speicherfähig macht.
Selbstenthältlich: JWTs enthalten alle notwendigen Informationen über den Benutzer und das Token selbst.
Überprüfbar und verschlüsselbar: JWTs können signiert und verschlüsselt werden, um die Datenintegrität und -vertraulichkeit zu gewährleisten.

Ein typisches JWT sieht so aus:

Dieses JWT besteht aus drei durch Punkte getrennten Teilen:

Header: Enthält Metadaten über das Token, wie den Tokentyp und den Signaturalgorithmus.
Payload: Enthält Informationen über die Identität und das Token selbst.
Signatur: Überprüft die Integrität des Tokens.

Sowohl der Header als auch die Nutzdaten sind base64-kodierte JSON-Objekte. Das obige JWT kann wie folgt dekodiert werden:

Mithilfe von JWT kann der Client das Token entschlüsseln und die Benutzerinformationen extrahieren, ohne zusätzliche Anfragen an den Identity Provider stellen zu müssen. Um mehr über JWT zu erfahren, besuchen Sie JSON Web Token (JWT).

Zusammenfassung

Wir haben in diesem Artikel viele Themen behandelt. Lassen Sie uns die wichtigsten Punkte anhand eines Beispiels zusammenfassen:

Stellen Sie sich vor, Sie haben eine Webanwendung, AppA, die eine Identity- und Access-Management (IAM) Lösung benötigt. Sie wählen Logto, einen Identity Provider, der OpenID Connect (OIDC) für die Authentifizierung verwendet. Da OIDC auf OAuth 2.0 aufbaut, unterstützt Logto auch die Autorisierung für Ihre Anwendung.

Um die Nutzung für Ihre Benutzer zu vereinfachen, aktivieren Sie "Mit Google anmelden" in Logto. Dies verwendet OAuth 2.0, um Autorisierungsdaten und Benutzerinformationen zwischen Logto und Google auszutauschen.

Nachdem sich der Benutzer über Logto bei AppA angemeldet hat, erhält AppA ein ID-Token, welches ein JSON Web Token (JWT) ist, das die Benutzerinformationen enthält.

Mit dem Wachstum Ihres Unternehmens starten Sie eine neue Anwendung, AppB, die ebenfalls eine Benutzerauthentifizierung benötigt. Da Logto bereits eingerichtet ist, können Sie denselben Authentifizierungsablauf für AppB wiederverwenden. Ihre Benutzer können sich jetzt mit einem einzigen Satz von Zugangsdaten bei sowohl AppA als auch AppB anmelden, eine Funktion, die als Single Sign-on (SSO) bekannt ist.

Später bittet ein Geschäftspartner Sie, ihr enterprise SSO-System zu verbinden, das Security Assertion Markup Language (SAML) verwendet. Sie stellen fest, dass Logto SAML-Verbindungen unterstützt, und richten eine Verbindung zwischen Logto und dem SSO-System des Partners ein. Jetzt können sich Benutzer aus der Organisation des Partners ebenfalls mit ihren bestehenden Zugangsdaten bei AppA und AppB anmelden.

Ich hoffe, dieser Artikel hat diese Konzepte für Sie verständlich gemacht. Für detailliertere Erklärungen und Beispiele, besuchen Sie Auth Wiki. Wenn Sie nach einer IAM-Lösung für Ihre Anwendung suchen, sollten Sie die Verwendung eines verwalteten Dienstes wie Logto in Betracht ziehen, um Zeit und Aufwand zu sparen.

Probieren Sie Logto Cloud kostenlos aus

Was ist IAM?#

Authentifizierung vs. Autorisierung#

OAuth#

OpenID Connect (OIDC)#

Beispiel: „Mit Google anmelden“#

SAML#

Wie vergleicht sich SAML mit OIDC?#

Single Sign-on (SSO)#

Wie funktioniert SSO?#

Beispiel für OIDC-basiertes SSO#

Enterprise SSO#

Beispiel: Hinzufügen eines Enterprise SSO Providers#

JWT#

Zusammenfassung#

Was ist IAM?#

Authentifizierung vs. Autorisierung#

OAuth#

OpenID Connect (OIDC)#

Beispiel: „Mit Google anmelden“#

SAML#

Wie vergleicht sich SAML mit OIDC?#

Single Sign-on (SSO)#

Wie funktioniert SSO?#

Beispiel für OIDC-basiertes SSO#

Enterprise SSO#

Beispiel: Hinzufügen eines Enterprise SSO Providers#

JWT#

Zusammenfassung#

Was ist IAM?

Authentifizierung vs. Autorisierung

OAuth

OpenID Connect (OIDC)

Beispiel: „Mit Google anmelden“

SAML

Wie vergleicht sich SAML mit OIDC?

Single Sign-on (SSO)

Wie funktioniert SSO?

Beispiel für OIDC-basiertes SSO

Enterprise SSO

Beispiel: Hinzufügen eines Enterprise SSO Providers

JWT

Zusammenfassung

Was ist IAM?

Authentifizierung vs. Autorisierung

OAuth

OpenID Connect (OIDC)

Beispiel: „Mit Google anmelden“

SAML

Wie vergleicht sich SAML mit OIDC?

Single Sign-on (SSO)

Wie funktioniert SSO?

Beispiel für OIDC-basiertes SSO

Enterprise SSO

Beispiel: Hinzufügen eines Enterprise SSO Providers

JWT

Zusammenfassung