Identität und Zugriff: Authentifizierung, Autorisierung, OAuth 2.0 und OpenID Connect

Authentifizierung und Autorisierung

Jede Anfrage an die Essenslieferplattform wirft zwei getrennte Fragen auf. Authentifizierung fragt Wer ist das? und wird durch Nachweise beantwortet: ein Passwort, einen Passkey, ein Zertifikat, ein signiertes Token. Autorisierung fragt Darf diese Person das tun, mit diesem Objekt, jetzt? und wird durch eine Richtlinie beantwortet: Dieser Kunde darf diese Bestellung lesen, weil er sie aufgegeben hat; dieser Kurier darf diese Abholadresse sehen, weil ihm die Lieferung zugewiesen ist. Auch HTTP hält beides auseinander: 401 Unauthorized bedeutet, dass der Anfrage eine gültige Authentifizierung fehlt, während 403 Forbidden bedeutet, dass der Aufrufer bekannt ist, die Aktion aber nicht darf.

Die Unterscheidung ist architektonisch wichtig, weil beides an verschiedenen Stellen gelöst wird. Authentifizierung wird am besten in einem einzigen Identity Provider (IdP) zentralisiert, dem alle Anwendungen vertrauen, sodass Passwortregeln, Multi-Faktor-Authentifizierung, Kontowiederherstellung und Sperrung nur einmal implementiert werden. Autorisierung ist von Natur aus verteilt: Nur der Bestellservice weiß, wem eine Bestellung gehört, also muss die endgültige Entscheidung über eine Bestellung dort fallen, auch wenn grobe Prüfungen schon vorher am API-Gateway stattfinden. Die meisten Verstöße gegen die Zugriffskontrolle in den OWASP Top 10 entstehen, weil beides verwechselt wird: ein Endpoint, der prüft, ob das Token gültig ist, und dann jedes Objekt zurückgibt, dessen ID er erhält.

Passwörter, Multi-Faktor-Authentifizierung und Passkeys

Passwörter sind nach wie vor das häufigste Authentifizierungsmittel, und die Digital Identity Guidelines des NIST sind die am weitesten befolgten Regeln dafür. Revision 4 von SP 800-63B, veröffentlicht im Juli 2025, kehrt mehrere lang gepflegte Gewohnheiten um. Länge zählt mehr als Zusammensetzung: Ein Passwort, das als einziger Faktor dient, muss mindestens 15 Zeichen lang sein (mindestens 8, wenn es nur als Teil einer Multi-Faktor-Authentifizierung genutzt wird), und prüfende Systeme sollten mindestens 64 Zeichen akzeptieren, einschließlich Leerzeichen und Unicode. Sie dürfen keine Kompositionsregeln vorschreiben, etwa eine Ziffer und ein Sonderzeichen zu verlangen; solche Regeln machen Passwörter schwerer zu merken, ohne sie wesentlich schwerer zu erraten. Sie müssen neue Passwörter mit einer Sperrliste gängiger, erwartbarer und kompromittierter Passwörter abgleichen. Sie dürfen keine regelmäßigen Wechsel erzwingen, sondern nur dann einen Wechsel, wenn es Hinweise auf eine Kompromittierung gibt. Sie müssen Passwortmanager zulassen und sollten das Einfügen erlauben, dürfen keine vor der Anmeldung lesbaren Passworthinweise anbieten und nicht nach Sicherheitsfragen fragen. Fehlgeschlagene Versuche müssen per Rate Limiting begrenzt werden.

Multi-Faktor-Authentifizierung (MFA) kombiniert Faktoren unterschiedlicher Art: etwas, das Sie wissen (ein Passwort), etwas, das Sie haben (ein Smartphone oder einen Sicherheitsschlüssel), und etwas, das Sie sind (ein Fingerabdruck, meist nur zum Entsperren eines Geräts genutzt). Sie vereitelt das meiste Credential Stuffing, bei dem Angreifer Kombinationen aus Benutzername und Passwort durchprobieren, die von anderen Websites geleakt wurden. Nicht alle zweiten Faktoren sind gleichwertig: Per SMS gesendete Einmalcodes lassen sich durch SIM-Swapping stehlen, und kein Einmalcode, ob per SMS oder aus einer Authenticator-App, widersteht Phishing, weil ein Nutzer dazu gebracht werden kann, ihn auf einer gefälschten Website einzugeben, die ihn sofort weiterleitet. Die NIST-Richtlinien verlangen deshalb, dass Dienste auf Authentication Assurance Level 2 mindestens eine phishing-resistente Option anbieten und auf Level 3 eine verwenden.

Ein Passkey ist die phishing-resistente Option, die die meisten Nutzer tatsächlich verwenden können. Passkeys sind FIDO2-Anmeldedaten, aufgebaut auf der Web Authentication API (WebAuthn) des W3C und dem Client to Authenticator Protocol (CTAP) der FIDO Alliance. Bei der Registrierung erzeugt das Gerät des Nutzers ein neues Schlüsselpaar für diese Website; der Server speichert nur den öffentlichen Schlüssel. Bei der Anmeldung sendet der Server eine zufällige Challenge, und das Gerät signiert sie mit dem privaten Schlüssel, nachdem der Nutzer es per Fingerabdruck, Gesicht oder PIN entsperrt hat. Weil der Browser die Anmeldedaten an den Origin der Website bindet, kann eine täuschend ähnliche Phishing-Website keine gültige Signatur erhalten, und weil der Server kein gemeinsames Geheimnis hält, liefert ein Datenbankeinbruch nichts, was ein Angreifer wiederverwenden könnte. Passkeys können gerätegebunden sein (auf einem Hardware-Sicherheitsschlüssel) oder von einer Plattform oder einem Passwortmanager zwischen den Geräten eines Nutzers synchronisiert werden; die NIST-Leitlinien von 2025 akzeptieren synchronisierte Passkeys auf Level 2, während Level 3 einen nicht exportierbaren Schlüssel verlangt.

Die architektonische Schwachstelle jedes Authentifizierungsverfahrens ist die Kontowiederherstellung. Lässt sich ein verlorener Passkey durch einen Klick auf einen per E-Mail gesendeten Link ersetzen, ist das ganze System nur so stark wie das E-Mail-Konto. Wiederherstellungsabläufe verdienen ein eigenes Bedrohungsmodell, Rate Limits, Benachrichtigungen an die anderen Geräte des Nutzers und bei wertvollen Konten Wartezeiten oder Prüfungen durch Menschen.

Sessions und Tokens

Hat sich ein Nutzer authentifiziert, muss das System seine späteren Anfragen erkennen, ohne erneut zu fragen. Es gibt zwei grundlegende Entwürfe. Bei einer serverseitigen Session speichert der Server die Session (Nutzer, Ablaufzeit, vielleicht Rollen) und gibt dem Browser eine lange zufällige Session-ID in einem Cookie. Bei einem Entwurf mit in sich geschlossenen Tokens signiert der Aussteller ein Token, das die Claims enthält, typischerweise ein JSON Web Token (JWT, RFC 7519), und jeder Service, der den öffentlichen Schlüssel des Ausstellers kennt, kann es ohne Nachschlagen validieren.

Für Browseranwendungen ist eine serverseitige Session in einem Cookie mit den Attributen HttpOnly (für JavaScript unsichtbar), Secure (nur HTTPS) und SameSite kaum zu übertreffen. Single-Page-Anwendungen setzen zunehmend auf ein Backend for Frontend (BFF): Der Browser hält nur ein Session-Cookie für sein eigenes kleines Backend, das die OAuth-Tokens verwahrt und die APIs in seinem Auftrag aufruft, ein Ansatz, den die Leitlinien der IETF-OAuth-Arbeitsgruppe für browserbasierte Anwendungen empfehlen. JWTs glänzen zwischen Services und in mobilen Apps, wo eine zustandslose Prüfung an jeder Station einen zentralen Engpass vermeidet.

import jwt  # PyJWT
from jwt import PyJWKClient

ISSUER = "https://id.fooddelivery.example/"
jwks = PyJWKClient(ISSUER + ".well-known/jwks.json")  # issuer's public keys

def verify_access_token(token: str) -> dict:
    signing_key = jwks.get_signing_key_from_jwt(token)
    return jwt.decode(
        token,
        signing_key.key,
        algorithms=["RS256"],      # pinned: never read from the token header
        audience="orders-api",      # the token must be meant for this API
        issuer=ISSUER,
        options={"require": ["exp", "iat", "sub"]},
    )  # raises an exception on any failure: fail closed

OAuth 2.0: delegierte Autorisierung

OAuth 2.0 (RFC 6749, 2012) löst ein bestimmtes Problem: einer Anwendung zu erlauben, im Namen eines Nutzers zu handeln, ohne dessen Passwort zu erfahren. Davor fragte ein Dienst, der Ihre Kontakte importieren wollte, nach Ihrem E-Mail-Passwort. OAuth definiert vier Rollen: den Ressourcenbesitzer (den Nutzer), den Client (die Anwendung, die Zugriff möchte), den Autorisierungsserver (der den Nutzer authentifiziert, um Zustimmung bittet und Tokens ausstellt) und den Ressourcenserver (die API mit den Daten). Der Client erhält ein Access Token, das durch Scopes (etwa orders:read), eine Laufzeit und eine Audience begrenzt ist, und oft ein Refresh Token, um neue Access Tokens zu erhalten, ohne den Nutzer erneut zu fragen.

OAuth definiert mehrere Wege, Grants genannt, um ein Token zu erhalten. Für jede Anwendung, die für einen Nutzer handelt, ob serverseitige Web-App, Single-Page-App oder mobile App, ist der empfohlene Grant der Authorization-Code-Flow mit PKCE (Proof Key for Code Exchange, RFC 7636, 2015). Der Client erzeugt zuerst einen zufälligen code_verifier und sendet nur dessen SHA-256-Hash, die code_challenge, wenn er den Nutzer zum Autorisierungsserver umleitet. Nachdem sich der Nutzer angemeldet und zugestimmt hat, leitet der Autorisierungsserver mit einem kurzlebigen Autorisierungscode zurück. Der Client tauscht den Code dann in einer direkten Back-Channel-Anfrage gegen Tokens ein und sendet dabei den ursprünglichen Verifier; der Server prüft, ob dessen Hash zur Challenge passt. Ein Angreifer, der den Code abfängt, etwa eine bösartige mobile App, die für dieselbe Redirect-Adresse registriert ist, kann ihn ohne den Verifier nicht einlösen, und der hat den Client nie verlassen.

Der Client-Credentials-Grant deckt den Fall ohne Nutzer ab: Ein Service erhält ein Token in eigener Befugnis, zum Beispiel der Dispositionsservice, der die API eines Kartenpartners aufruft, oder das System eines Partners, das die Bestellstatus-API der Plattform aufruft. Der Client sollte sich am Token-Endpoint mit einem privaten Schlüssel (einer signierten JWT-Assertion) oder Mutual TLS (RFC 8705) authentifizieren statt mit einem gemeinsamen Geheimnis. Von zwei älteren Grants wird inzwischen abgeraten: dem Implicit Grant, der Tokens in der URL des Browsers zurückgab, und dem Resource Owner Password Credentials Grant, bei dem der Client das Passwort des Nutzers einsammelte und damit den Zweck von OAuth zunichtemachte. RFC 9700, die im Januar 2025 veröffentlichte OAuth 2.0 Security Best Current Practice, hält diese Lehren fest, darunter den exakten Abgleich von Redirect-Adressen und absendergebundene Tokens.

OAuth 2.1 fasst OAuth 2.0 und diese bewährten Praktiken in einem Dokument zusammen: PKCE ist für den Authorization-Code-Flow Pflicht, Implicit und Password Grant entfallen, Redirect-Adressen müssen exakt übereinstimmen, und Bearer-Tokens dürfen nicht mehr in URL-Query-Strings gesendet werden. Zum Zeitpunkt der Abfassung (Oktober 2026) ist es noch ein IETF-Internet-Draft (Draft 16, September 2026), kein RFC, doch seine Regeln beschreiben bereits, was gut betriebene Autorisierungsserver tun.

OpenID Connect, Single Sign-on und SAML

OAuth stellt Access Tokens für APIs aus; es sagt dem Client für sich allein nicht, wer der Nutzer ist. Ein Access Token als Anmeldenachweis zu verwenden, ist ein bekannter Fehler, weil ein Token, das für eine Anwendung ausgestellt wurde, bei einer anderen wiederverwendet werden kann, die seine Audience nicht prüft. OpenID Connect (OIDC, Core 1.0, 2014) ergänzt die fehlende Identitätsschicht. Mit dem Scope openid gibt der Autorisierungsserver, der nun als OpenID Provider auftritt, zusätzlich ein ID-Token zurück: ein signiertes JWT für den Client, das den Issuer angibt, die stabile Kennung des Nutzers (sub), die Audience (die Client-ID), Ausstellungs- und Ablaufzeit, eine nonce, die es an diese Anmeldung bindet, und optional, wie und wann sich der Nutzer authentifiziert hat. OIDC standardisiert außerdem einen Userinfo-Endpoint und Discovery-Dokumente, die die Endpoints und Signaturschlüssel des Providers veröffentlichen. Die Faustregel: Das ID-Token ist für den Client, damit er weiß, wer sich angemeldet hat; das Access Token ist für die API, um Aufrufe zu autorisieren.

Single Sign-on (SSO) ergibt sich daraus fast von selbst: Hat ein Nutzer eine Session beim Identity Provider, kann jede Anwendung, die ihm vertraut, ihn ohne erneute Passwortabfrage anmelden, und die Deaktivierung des Kontos an einer Stelle sperrt den Zugriff überall. In Unternehmen nutzt SSO oft noch SAML 2.0 (ein OASIS-Standard von 2005), der signierte XML-Assertions über den Browser austauscht. Die Essenslieferplattform könnte OIDC für ihre eigenen Apps verwenden und SAML von großen Restaurantketten akzeptieren, deren Personal sich mit seinen Unternehmenskonten im Restaurantportal anmelden soll. Das Anlegen und Entfernen von Konten über Systeme hinweg wird meist mit SCIM (RFC 7643 und 7644) automatisiert.

Autorisierungsmodelle: RBAC, ABAC und Beziehungen

Authentifizierung sagt dem System, wer aufruft; ein Autorisierungsmodell entscheidet, was der Aufrufer tun darf. Drei Modelle dominieren, und reale Systeme kombinieren sie meist.

Beziehungsbasierte Zugriffskontrolle ist vor allem durch Googles Paper von 2019 über Zanzibar bekannt, das globale Autorisierungssystem hinter Google Drive, Calendar, YouTube und vielen anderen Produkten. Zanzibar speichert Relationstupel der Form object#relation@user, wertet Berechtigungen aus, indem es ihnen folgt, und verwendet Konsistenz-Tokens, damit eine Berechtigungsprüfung nie gegen Daten ausgewertet wird, die älter sind als der Inhalt, den sie schützt; das ist das sogenannte New-Enemy-Problem: Wer jemanden aus einem Dokument entfernt und dann vertrauliche Inhalte hinzufügt, darf ihn diese nicht sehen lassen. Davon inspirierte Open-Source-Systeme sind unter anderem SpiceDB, OpenFGA und Ory Keto.

Unabhängig vom Modell hilft es, den Policy Decision Point (PDP), der die Richtlinie auswertet und mit „erlauben“ oder „verweigern“ antwortet, vom Policy Enforcement Point (PEP) zu trennen, dem Code im Gateway oder Service, der die Frage stellt und die Antwort durchsetzt. Universelle Policy-Engines wie Open Policy Agent (OPA, ein Graduated-Projekt der Cloud Native Computing Foundation, mit Richtlinien in der Sprache Rego) und Cedar (2023 von Amazon Web Services als Open Source veröffentlicht) lassen Richtlinien in versionierten Dateien leben, wie Code testen und im Prozess oder als Sidecar nahe am Service auswerten. Eine sinnvolle Schichtung auf der Plattform ist: Das API-Gateway weist Anfragen ohne gültiges Token oder ohne passenden Scope ab (grob), und jeder Service entscheidet Fragen auf Objektebene mit Daten, die nur er hat (fein). Broken Object Level Authorization ist genau deshalb das erste Risiko in den OWASP API Security Top 10 (Ausgabe 2023), weil die feine Prüfung diejenige ist, die Teams vergessen.

Workload Identity: wenn der Aufrufer ein Service ist

Services authentifizieren sich weit öfter gegenüber anderen Services, als Menschen sich anmelden, und doch sind Service-Zugangsdaten oft die schwächsten: ein langlebiger API-Schlüssel in einer Umgebungsvariable, von mehreren Services geteilt und nie rotiert. Gelangt dieser Schlüssel über ein Log, ein Repository oder ein Container-Image nach außen, wird der Angreifer zum Service. Workload Identity ersetzt solche Secrets durch Identitäten, die die Plattform dem laufenden Workload ausstellt, nachdem sie geprüft hat, was der Workload ist.

Der offene Standard ist SPIFFE (Secure Production Identity Framework for Everyone), ein Graduated-Projekt der Cloud Native Computing Foundation. Er benennt jeden Workload mit einem URI wie spiffe://fooddelivery.example/ns/prod/sa/orders und stellt ein kurzlebiges, automatisch rotiertes Dokument als Nachweis aus, eine sogenannte SVID, meist ein X.509-Zertifikat (oder ein JWT). Die Referenzimplementierung SPIRE attestiert Knoten und Workload (zum Beispiel dessen Kubernetes-Namespace und Service-Account), bevor sie die Identität ausstellt. Services nutzen die Zertifikate dann für Mutual TLS, sodass der Zahlungsservice weiß, dass der Aufrufer wirklich der Bestellservice ist, und anhand der Identität autorisieren kann. Cloud-Plattformen bieten Entsprechungen (Rollen für Workloads, Managed Identities, Workload Identity Federation), und CI-Systeme wie GitHub Actions können ein signiertes OIDC-Token gegen kurzlebige Cloud-Zugangsdaten eintauschen, sodass Pipelines keine gespeicherten Schlüssel brauchen. Wie man mit diesen Identitäten ein Netzwerk ohne implizites Vertrauen aufbaut, ist Thema von Zero Trust.