Kartierung des Authentifizierungs-Wortschatzes: API-Schlüssel, Sessions, JWT, OAuth2, OIDC, SSO

Ein Entwickler fügt einem Projekt „Mit Google anmelden“ hinzu, erhält einen Zugriffstoken zurück und hält die Arbeit für abgeschlossen. Dann stellt ein Kollege eine einfache Frage: Wie weiß die App eigentlich, um welchen Benutzer es sich handelt? Oft lautet die ehrliche Antwort, dass sie es nicht weiß, denn was implementiert wurde, ist Delegierter Autorisierungsauftrag und nicht Anmeldung. Begriffe wie JWT, Session, OAuth2, OIDC und SSO werden in der Regel einzeln erklärt, was genau dazu führt, dass sie miteinander verwechselt werden. Dieser Artikel ordnet sie alle auf einer einzigen Karte ein, damit Sie erkennen können, welches Problem ein bestimmtes Element Ihres Technologiestacks tatsächlich löst, und das richtige Werkzeug für das nächste Problem auswählen können.

Zwei Fragen hinter jedem Auth-Mechanismus

Fast alles in diesem Bereich beantwortet eine von zwei Fragen.

• Authentifizierung fragt Wer sind Sie? Es handelt sich um den Prozess der Überprüfung einer Identität – egal, ob es sich dabei um eine Person, einen Backend-Dienst oder ein Gerät handelt.
• Autorisierung fragt Was dürfen Sie tun? Sie erfolgt nach der Bestätigung der Identität und entscheidet, welche Ressourcen und Aktionen verfügbar sind.

HTTP kodiert diese Trennung bereits in seinen Statuscodes. Eine 401 Unauthorized-Antwort bedeutet, dass der Anrufer nicht nachgewiesen hat, wer er ist (trotz des irreführenden Namens geht es dabei um die Authentifizierung). Eine 403 Forbidden-Antwort bedeutet, dass der Server genau weiß, wer anruft, den Antrag aber dennoch ablehnt. Wenn Ihre API bei fehlendem Token 403 oder bei einem Benutzer ohne Rolle 401 zurückgibt, können die Clients nicht erkennen, ob sie zur Anmeldung auffordern oder eine „Kein Zugriff“-Meldung anzeigen sollen.

Eine physische Analogie hilft. An einem Büroeingang überprüft ein Wachmann Ihren Mitarbeiterausweis – das ist die Authentifizierung. Im Inneren öffnet Ihr Ausweis bestimmte Türen und nicht andere – das ist die Autorisierung. Ein Schritt stellt die Identität fest, der andere gewährt Berechtigungen, und ein System kann den ersten Schritt bestehen, beim zweiten jedoch versagen. Für eine genauere Betrachtung, wo jede Überprüfung im Anwendungscode stattfinden sollte, sehen Sie Authentifizierung versus Autorisierung und wo jede dazu gehört.

Halten Sie diese beiden Fragen im Hinterkopf, wenn Sie den weiteren Ablauf betrachten. Jedes der unten aufgeführten Mechanismen lässt sich leichter verstehen, sobald man weiß, welche Frage er beantwortet.

API-Schlüssel: Identifizierung eines Clients, nicht einer Person

API-Schlüssel sind die einfachste Form der Client-Authentifizierung. Der Anbieter stellt Ihnen eine eindeutige Zeichenkette zur Verfügung, die Sie mit jeder Anfrage senden, und der Server vergleicht sie mit den Schlüsseln, die er gespeichert hat. Viele APIs akzeptieren sie als Träger-Zertifikat im Standard-Header:

Authorization: Bearer your-api-key-here

Andere Anbieter verwenden einen benutzerdefinierten Header wie X-API-Key; die Idee ist dieselbe. Der Schlüssel beschreibt keine Person – es handelt sich um einen undurchsichtigen Wert, weshalb der Server nachschauen muss, um herauszufinden, welches Konto anruft. Er verfügt standardmäßig über keine Ablaufzeit, es sei denn, Sie legen eine fest, und wer einen durchgesickerten Schlüssel besitzt, hat denselben Zugriff wie sein rechtmäßiger Besitzer. Deshalb liegen die Verantwortung für Rotation, Einschränkung des Zugriffs und sicheres Speichern bei Ihnen.

Die HTTP-Basic-Autentifizierung, bei der ein im Header gesendeter, base64-kodierter Benutzername und Passwort verwendet werden, existiert weiterhin. Base64 ist eine Kodierung, keine Verschlüsselung, weshalb die Basic-Autentifizierung nur über TLS sicher ist und außer bei sehr einfachen internen Tools kaum gerechtfertigt werden kann. API-Schlüssel sind die gängigere, leichtgewichtige Alternative und eignen sich gut, wenn man beide Endpunkte der Verbindung kontrolliert oder ein Service pro Konto Abrechnungen durchführt und Geschwindigkeitsbeschränkungen setzt.

Typische Anwendungsbereiche für API-Schlüssel:

• APIs für KI-Modelle
• Zahlungsgateways
• Wetter- und andere Datendienste-APIs
• Aufrufe zwischen eigenen Backend-Diensten

Bemerken Sie, was auf dieser Liste fehlt: Endbenutzer, die sich in Ihrer App anmelden. Ein API-Schlüssel identifiziert eine aufrufende Anwendung oder ein Konto – nicht die Person vor dem Bildschirm.

Sessions: Serverseitiger Zustand hinter einem Cookie

Lange bevor JWTs populär wurden, waren Sessions die übliche Methode, um Benutzer angemeldet zu halten, und sie bleiben eine gute Option für serverseitig generierte Anwendungen.

Der Ablauf ist einfach. Der Benutzer gibt seine Anmeldeinformationen ein, der Server überprüft diese und erstellt eine Session-Eintragung in einem Speicherort (im Arbeitsspeicher, in Redis oder in einer Datenbank), wobei die Antwort ein Cookie enthält, das nur die Session-ID enthält. Bei jeder nachfolgenden Anfrage sendet der Browser das Cookie zurück, und der Server sucht anhand der ID nach der Session sowie dem dazugehörigen Benutzer.

Dieses Design ist zustandsbasiert, doch genau das ist auch seine Stärke. Der Server besitzt die aktuelle Zustandsinformation, wodurch das Abmelden eines Benutzers oder das Aufheben einer kompromittierten Session genauso einfach ist wie das Löschen eines Eintrags. Das Cookie selbst enthält nichts Sensibles außer einer zufälligen Identifikationsnummer.

Die Kosten treten auf, wenn man horizontal skaliert. Wenn mehrere Server den Verkehr bewältigen müssen, müssen alle auf denselben Session-Speicher zugreifen können; andernfalls erscheint ein Benutzer, der sich auf einer Instanz angemeldet hat, auf der nächsten als anonym. Eine gemeinsam genutzte Redis-Instanz löst dieses Problem in der Praxis gut, stellt aber einen weiteren Komponenten dar, die richtig eingerichtet, überwacht und konfiguriert werden muss. Ein falsch konfigurierter Session-Speicher ist genau die Art von Problem, das zum ungünstigsten Zeitpunkt während eines Releases auftaucht.

Sessions eignen sich weiterhin hervorragend für:

• Traditionelle, auf Servern bereitgestellte Webanwendungen
• Admin-Dashboards
• Anwendungen, bei denen eine sofortige Revokation wichtiger ist als Zustandslosigkeit

JWT: selbstständig, signiert und lesbar

Ein JSON Web Token ist ein signiertes JSON-Objekt, das Angaben wie Benutzer-ID, Rollen und Ablaufzeit enthält. Es besteht aus drei base64url-kodierten Abschnitten, die durch Punkte miteinander verbunden sind:

Header.Payload.Signature

Der Header gibt den Signieralgorithmus an, der Payload enthält die Angaben, und die Signatur ermöglicht es dem Server zu überprüfen, dass weder der Header noch der Payload von jemandem ohne den Signierschlüssel verändert wurden. Da die Angaben innerhalb des Tokens übertragen werden, kann ein Server eine Anfrage authentifizieren, indem er die Signatur überprüft und den Payload liest – ohne auf eine Datenbank zugreifen zu müssen. Genau diese Eigenschaft macht JWTs für stateless und verteilte Systeme geeignet.

Gesiegelt bedeutet nicht geheim

Der häufigste Irrtum besteht darin, dass ein JWT seinen Inhalt verbergen würde. Das ist nicht der Fall. Ein Standard-JWT wird signiert, aber nicht verschlüsselt, und jeder, der es besitzt, kann die Nutzlast mit einer einzigen Base64-Verarbeitung entschlüsseln. Legen Sie niemals Passwörter, persönliche Daten, die Sie dem Benutzer nicht zeigen möchten, oder interne Geheimnisse in die Claims, unter der Annahme, sie seien privat. Wenn ein mit JWT verbundenes Problem auftritt, liegt oft diese falsche Annahme daran. (Verschlüsselte Token existieren zwar nach der JWE-Spezifikation, doch sie bilden ein separates Format und sind selten das, was in Tutorials unter „JWT“ verstanden wird.)

Zugriffs- und Erneuerungstoken

Weil ein JWT bis zu seinem Ablauf gültig bleibt, verwendet man üblicherweise zwei Token zusammen:

• Zugriffs-Token: Kurzlebig, in der Regel 15 Minuten bis eine Stunde lang, und mit jeder API-Anfrage übermittelt.

Auffrischungstoken: langfristig gültig, von Tagen bis Wochen, und wird ausschließlich verwendet, um ein neues Zugriffstoken zu erhalten, ohne dass der Benutzer erneut sich anmelden muss.

Speichern Sie das Auffrischungstoken in einem HttpOnly-Cookie anstatt in localStorage, wo jedes eingeschleuste Skript darauf zugreifen könnte. Die kurze Gültigkeitsdauer des Zugriffstokens begrenzt den Schaden bei einem Leck, während die Logik zur Aufhebung der Berechtigungen im Auffrischungstoken untergebracht werden kann.

JWTs eignen sich gut für APIs, mobile Clients, Single-Page-Apps und verteilte Dienste. Sie haben Sessions nicht überflüssig gemacht; stattdessen tauschen sie eine einfache Aufhebung gegen Zustandslosigkeit ein, und die richtige Wahl hängt von Ihrer Architektur ab. Der Vergleich von Sessions und JWTs als Node.js-Authentifizierungsmodelle geht detailliert auf diesen Kompromiss ein.

OAuth 2.0: Delegierter Zugriff, keine Anmeldung

OAuth 2.0 ist das Konzept, das am häufigsten in die falsche Schublade gelegt wird. Es handelt sich dabei um ein Authorization Framework, nicht um ein Authentifizierungsprotokoll. Seine Aufgabe besteht darin, einer Anwendung zu ermöglichen, im Namen des Benutzers auf Ressourcen zuzugreifen, die von einem anderen Service gehalten werden, ohne dass der Benutzer jemals sein Passwort abgeben muss.

Im üblichen Authorization-Code-Flow leitet Ihre Anwendung den Benutzer zur Zustimmungsoberfläche des Anbieters um, auf der gefragt wird: „Erlauben Sie dieser Anwendung, Ihre Google Drive-Dateien anzusehen?“ Wenn der Benutzer zustimmt, leitet der Anbieter mit einem kurzfristig gültigen Authorization-Code zurück. Ihr Backend tauscht diesen Code gegen ein Zugriffstoken aus und ruft anschließend mit diesem die API des Anbieters auf.

Dieses Zugriffstoken stellt eine Berechtigung dar, auf bestimmte Ressourcen zuzugreifen. Es ist keine Angabe darüber, wer der Benutzer ist, und die OAuth2-Spezifikation definiert weder sein Format noch verlangt sie, dass Ihre Anwendung es lesen kann. Die Annahme, dass das Eintreffen eines Zugriffstokens Beweis dafür ist, dass der Benutzer eingeloggt ist, ist der klassische Fehler aus dem ersten Szenario und hat zu echten Sicherheitslücken geführt – beispielsweise wenn ein Token, das einer Anwendung ausgestellt wurde, von einer anderen als Identitätsnachweis akzeptiert wird.

OAuth2 ist so konzipiert, Fragen wie folgende zu beantworten:

• Darf diese Anwendung die Drive-Dateien des Benutzers lesen?
• Darf diese Anwendung auf die Repositorien des Benutzers zugreifen?

Es ist nicht dafür konzipiert, zu beantworten: Wer ist dieser Benutzer?

OpenID Connect: die Identitätsschicht auf OAuth2

Falls OAuth2 angibt, auf welche Ressourcen eine Anwendung Zugriff haben darf, fügt OpenID Connect die fehlende Information hinzu, um zu bestimmen, wer der Benutzer ist. OIDC ist eine schlanke Identitätsschicht, die auf OAuth2 aufbaut und dessen Umleitungen sowie Tokenaustausch wiederverwendet. Wenn Sie auf „Mit Google anmelden“ klicken, wird im Hintergrund OIDC genutzt und nicht reines OAuth2.

Nach der Authentifizierung des Benutzers gibt ein OIDC-Anbieter zwei Token mit unterschiedlichen Zwecken zurück:

• Ein ID-Token, das ein JWT ist, das den Benutzer beschreibt: eine stabile, eindeutige Identifikationsnummer sowie in der Regel Angaben wie Name und E-Mail.
• Ein Zugriffs-Token, das es Ihrer Anwendung ermöglicht, im Namen des Benutzers APIs aufzurufen.

Das ID-Token dient dazu, den Benutzer in Ihrer Anwendung zu authentifizieren. Das Zugriffstoken berechtigt Ihre Anwendung zu weiteren Aktionen. Ihr Backend sollte die Signatur, den Aussteller, das Zielpublikum sowie das Ablaufdatum des ID-Tokens überprüfen, bevor es dessen Angaben für gültig hält, und Benutzerkonten anhand eines stabilen Subjektidentifikators statt anhand einer änderbaren E-Mail-Adresse verknüpfen. Aus dieser Sicht kann OAuth2 allein kein Anmelden gewährleisten; OIDC vervollständigt dies.

SSO: ein Benutzererlebnis, das durch Protokolle bereitgestellt wird

Single Sign-On wird oft mit den Protokollen verwechselt, die es umsetzen. SSO ist ein Muster für das Benutzererlebnis: Man authentifiziert sich einmal und kann anschließend ohne erneutes Anmelden zwischen mehreren Systemen wechseln. Google ist ein bekanntes Beispiel – man meldet sich einmal an, und Gmail, Drive, Kalender sowie YouTube erkennen einen wieder.

Zwei Protokolle übernehmen den größten Teil der Arbeit hinter SSO:

• SAML: basiert auf XML und ist ausgereift; dominiert in Unternehmensumgebungen wie Firmenportalen, CRM-Dashboards und internen Tools.
• OpenID Connect: basiert auf JSON und JWT, jünger und die übliche Wahl für Web- sowie Mobile-Anwendungen.

SAML ist bekanntermaßen schwierig in der Implementierung und Fehlerbehebung, weshalb OIDC im Allgemeinen der einfachere Weg für neue Systeme ist. SAML behält weiterhin seine Relevanz, wenn eine Integration mit Unternehmens-Identitätsanbietern erforderlich ist, die kein OIDC anbieten – und solche Anbieter werden weiterhin häufig genutzt.

Wenn jemand von Ihnen bittet, „SSO hinzuzufügen“, sollten Sie zunächst herausfinden, welches Protokoll der Identitätsanbieter unterstützt. Diese Antwort bestimmt anschließend die zu verwendenden Bibliotheken, die Konfiguration sowie die notwendigen Tests.

Wahl des Mechanismus

Zusammenfassend sieht ein grober Entscheidungshilfe-Leitfaden wie folgt aus:

• Ihre Dienstleistung wird von anderen Programmen aufgerufen, nicht von Menschen: API-Schlüssel, die begrenzt eingesetzt und regelmäßig ausgetauscht werden, oder OAuth2-Kundenanmeldeinformationen, falls ablaufende Token benötigt werden.
• Eine auf dem Server generierte Anwendung oder ein Admin-Panel mit eigenem Anmeldesystem: Sessions mit einem sicheren, HttpOnly-Cookie.
• Stateless-APIs, mobile Clients oder mehrere Dienste, die denselben Benutzer überprüfen: JWT-Zugriffstoken mit Erneuerungstokens.
• Ihre Anwendung muss auf Daten eines Benutzers in einem anderen Dienst zugreifen: OAuth 2.0.
• Sie möchten, dass Benutzer mit einem bestehenden Konto wie Google sich anmelden: OpenID Connect.
• Mitarbeiter benötigen einen einzigen Anmeldevorgang für viele interne oder SaaS-Tools: SSO über OIDC oder SAML, sofern der Identitätsanbieter dies erfordert.

Diese Optionen werden kombiniert. Ein typisches Produkt könnte OIDC für die Anmeldung verwenden, anschließend seine eigene Sitzung oder JWT ausgeben und gleichzeitig OAuth2-Zugriffstoken für Integrationslösungen Dritter bereithalten.

Häufige Fragen

Inwiefern unterscheiden sich Authentifizierung und Autorisierung in der Praxis? Die Authentifizierung überprüft die Identität und schlägt bei HTTP 401 fehl; die Autorisierung prüft Berechtigungen und schlägt bei 403 fehl. Es handelt sich um getrennte Schritte mit unterschiedlichen Fehlercodes, und ihre Kombination führt zu echten Sicherheitslücken.

Sollte man JWT oder Sitzungen verwenden? Sitzungen eignen sich hervorragend für serverseitig generierte Anwendungen, die einen gemeinsamen Sitzungsspeicher nutzen können. JWT sind sinnvoller für stateless APIs, mobile Clients und verteilte Systeme. Entscheiden Sie sich auf der Grundlage Ihrer Architektur und Revokationsanforderungen – nicht danach, welche Option moderner klingt.

Dient OAuth2 der Authentifizierung oder Autorisierung? Autorisierung. Es ermöglicht Anwendungen, im Namen eines Benutzers auf Ressourcen zuzugreifen, ohne zu überprüfen, wer dieser Benutzer ist. Für die Identitätsbestimmung sollte OpenID Connect verwendet werden, das OAuth2 genau zu diesem Zweck erweitert.

Kernpunkte

• Fassen Sie jeden Mechanismus unter einer Frage zusammen: Wer ruft an? oder Was dürfen sie tun?
• API-Schlüssel identifizieren Client-Anwendungen; sie enthalten keine Benutzeridentität und erfordern eine eigene Ablaufzeit sowie Regenerierung.
• Sessions speichern den Zustand auf dem Server, was eine einfache Revokation ermöglicht, aber im großen Maßstab einen gemeinsamen Speicher erfordert.
• JWTs sind signiert, nicht verschlüsselt; halten Sie Geheimnisse außerhalb des Payloads und Refresh-Tokens außerhalb von localStorage.
• OAuth2 gewährt delegierten Zugriff; OIDC fügt den ID-Token hinzu, der tatsächlich den Benutzer anmeldet.

SSO ist ein Prozess, der je nach Identitätsanbieter mit OIDC oder SAML umgesetzt wird.

Die meisten Verwirrungen in diesem Bereich, einschließlich der Verwechslung mit „Mit Google anmelden“ am Anfang, entstehen durch das Vermischen dieser beiden Fragestellungen. Halten Sie Identität und Berechtigungen getrennt, dann wird die Wahl zwischen diesen Tools zu einer Frage der Passung jedes Tools zur jeweiligen zu beantwortenden Frage.