Das Gebiet des [Identity- und Access-Managements (IAM)](https://auth.wiki/iam) ist in den letzten Jahren immer komplexer geworden. Die ausgefallenen Begriffe wie [OAuth](https://auth.wiki/oauth), [OpenID Connect (OIDC)](https://auth.wiki/openid-connect), [SAML](https://auth.wiki/saml), [SSO](https://auth.wiki/single-sign-on) und [JWT](https://auth.wiki/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. Jedes dieser Protokolle und Frameworks kann genauer untersucht werden. Dieser Artikel zielt darauf ab, ein grundlegendes Verständnis zu vermitteln. Für detaillierte Einblicke zu jedem Thema besuchen Sie [Auth Wiki](https://auth.wiki). ## 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. ```mermaid graph LR subgraph Benutzer Name E-Mail Rolle end API Benutzer -->|GET| API ``` 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?“ Die Autorisierung ist ein Teilbereich der Zugriffskontrolle. Zugriffskontrolle ist ein umfassenderes Konzept, das Autorisierung und andere Einschränkungen umfasst. Für weitere Details siehe [Zugriffskontrolle](https://auth.wiki/access-control). 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](https://auth.wiki/oauth-2.0), allgemein als OAuth bezeichnet, ist ein **Autorisierungs**framework, 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: ```mermaid sequenceDiagram autonumber actor Benutzer participant MyApp participant Google Benutzer->>MyApp: MyApp öffnen und
auf "Google Drive verbinden" klicken MyApp->>Google: Zu Google umleiten
mit Autorisierungsanfrage Google->>Benutzer: Gmail-Login-Aufforderung Benutzer->>Google: Anmelden Google->>Benutzer: Um Erlaubnis fragen, um
auf Google Drive zuzugreifen Benutzer->>Google: Zugriff auf MyApp gewähren Google->>MyApp: Zurückleiten zu MyApp
mit einem Access Token MyApp->>Google: Access Token verwenden, um
auf Google Drive zuzugreifen ``` 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. OAuth 2.0 definiert nicht, wie sich Benutzer bei Google authentifizieren (Schritte 3 und 4). Dieser Aspekt bleibt der Implementierung durch Google überlassen. 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](https://auth.wiki/access-token). ## OpenID Connect (OIDC) [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) ist eine **Authentifizierungs**schicht, die auf OAuth 2.0 aufbaut. Es fügt speziell für die Authentifizierung vorgesehene Funktionen hinzu, wie [ID Tokens](https://auth.wiki/id-token) und einen [UserInfo-Endpunkt](https://auth.wiki/userinfo-endpoint), 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: ```mermaid sequenceDiagram autonumber actor Benutzer participant MyApp participant Google Benutzer->>MyApp: Auf "Mit Google anmelden" klicken MyApp->>Google: Umleitung mit Authentifizierungsanfrage Google->>Benutzer: Gmail-Login-Aufforderung Benutzer->>Google: Anmelden Google->>Benutzer: Um Erlaubnis bitten, Benutzerdaten zu teilen Benutzer->>Google: Erlaubnis erteilen Google->>MyApp: Zurückleiten zu MyApp
mit ID- und Access-Tokens MyApp->>MyApp: Benutzerinformationen
aus ID-Token verifizieren und extrahieren ``` **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](https://auth.wiki/oauth-2.0-grant) von OAuth 2.0 und stellt so die Kompatibilität und Konsistenz zwischen den beiden Frameworks sicher. ## SAML [Security Assertion Markup Language (SAML)](https://auth.wiki/saml) ist ein auf XML basierendes Framework zum Austausch von **Authentifizierungs**- und **Autorisierungs**daten 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)](https://auth.wiki/sso) ist ein **Authentifizierungs**schema, 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)](https://auth.wiki/identity-provider), um Benutzeridentitäten zu verwalten. Der IdP authentifiziert den Benutzer und bietet Dienste wie Authentifizierung und Autorisierung für verbundene Anwendungen an. ```mermaid graph LR Benutzer --> AppA Benutzer --> AppB AppA <--> IdP[Identity Provider] AppB <--> IdP Benutzer -->|SSO| IdP ``` 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: ```mermaid sequenceDiagram actor Benutzer participant AppA participant AppB participant IdP Benutzer->>AppA: Zugang zu Anwendung A AppA->>IdP: Umleitung zu IdP IdP->>Benutzer: Anmeldeaufforderung Benutzer->>IdP: Anmeldeinformationen eingeben IdP->>AppA: ID-Token senden AppA->>Benutzer: Zugriff gewähren Benutzer->>AppB: Zugang zu Anwendung B AppB->>IdP: Umleitung zu IdP IdP->>IdP: Benutzer bereits authentifiziert IdP->>AppB: ID-Token senden AppB->>Benutzer: Zugriff gewähren ``` 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](https://auth.wiki/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): ```mermaid sequenceDiagram actor Benutzer participant MyApp participant IdP as MyApp IdP participant Banana as Banana IdP Benutzer->>MyApp: Auf "Anmelden" klicken MyApp->>IdP: Umleitung zu IdP IdP->>Benutzer: Anmeldeaufforderung Benutzer->>IdP: Banana-E-Mail angeben IdP->>Banana: Umleitung zu Banana IdP Banana->>Benutzer: Anmeldeaufforderung Benutzer->>Banana: Anmeldeinformationen eingeben Banana->>IdP: Antwort senden IdP->>MyApp: Antwort senden MyApp->>Benutzer: Zugriff auf MyApp gewähren und Benutzerdaten anzeigen ``` Die Umleitung zum IdP ist ein gängiges Muster in SSO-Abläufen. Dieser Ansatz ermöglicht es dem IdP, einen zentralen Punkt für Benutzersitzungen zu pflegen und gleichzeitig Authentifizierungs- und Autorisierungsdienste für mehrere Anwendungen bereitzustellen. ## JWT [JSON Web Token (JWT)](https://auth.wiki/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: ``` eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJmb28iLCJuYW1lIjoiSm9obiBEb2UifQ.XM-XSs2Lmp76IcTQ7tVdFcZzN4W_WcoKMNANp925Q9g ``` Dieses JWT besteht aus drei durch Punkte getrennten Teilen: ``` {{header}}.{{payload}}.{{signature}} ``` - **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: ```jsonc // Header { "alg": "HS256", "typ": "JWT" } // Payload { "sub": "foo", "name": "John Doe" } ``` 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)](https://auth.wiki/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](https://auth.wiki). Wenn Sie nach einer IAM-Lösung für Ihre Anwendung suchen, sollten Sie die Verwendung eines verwalteten Dienstes wie [Logto](https://logto.io) in Betracht ziehen, um Zeit und Aufwand zu sparen.