OAuth 2.0 / OpenID Connect

OAuth 2.0 und OpenID Connect (OIDC) sind die beiden Standards, auf denen moderne Anmeldungen und API-Zugriffe im Web aufbauen. OAuth 2.0 ist ein Autorisierungs-Framework, das es einer Anwendung erlaubt, im Namen eines Nutzers begrenzten Zugriff auf eine API zu erhalten, ohne dass das Passwort dieses Nutzers an die Anwendung weitergegeben wird. OpenID Connect erweitert OAuth 2.0 um eine Identitätsschicht und liefert verlässliche Aussagen darüber, wer sich tatsächlich angemeldet hat. Der Unterschied wird in der Praxis oft unscharf, ist aber zentral: OAuth beantwortet die Frage „Was darf diese Anwendung tun?", OIDC die Frage „Wer ist eingeloggt?".

Rollen und Begriffe

Beide Standards arbeiten mit denselben Akteuren. Der Resource Owner ist der Nutzer, dem die Daten gehören. Der Client ist die Anwendung, die Zugriff anfragt — etwa ein SPA, eine mobile App oder ein Backend-Dienst. Der Authorization Server stellt nach erfolgreicher Authentifizierung Token aus; in Unternehmen ist das typischerweise Entra ID, Google Workspace, Okta oder Keycloak. Der Resource Server ist die API, die das Token validiert und Daten zurückgibt. OIDC nennt den Authorization Server zusätzlich „OpenID Provider" und führt den ID Token als drittes Token neben Access und Refresh Token ein.

Die wichtigsten Flows

Welcher Flow zum Einsatz kommt, hängt vom Anwendungstyp ab. Falsche Wahl ist in Assessments eine häufige Schwachstelle, weil veraltete Tutorials noch den Implicit Flow zeigen.

Authorization Code mit PKCE (Proof Key for Code Exchange) ist heute der einzige korrekte Flow für interaktive Anmeldungen. PKCE schützt vor dem Abfangen des Authorization Codes, indem der Client bei Beginn einen geheimen Verifier generiert und nur dessen Hash an den Authorization Server schickt. Beim Token-Tausch wird der Verifier nachgereicht und serverseitig geprüft.

Token im Überblick

Access Token autorisieren API-Aufrufe und sind typischerweise kurzlebig (Minuten bis eine Stunde). Refresh Token erlauben dem Client, neue Access Token zu beschaffen, ohne den Nutzer erneut zu fragen — sie sind langlebig und müssen entsprechend geschützt werden. ID Token aus OIDC sind signierte JWTs mit Aussagen über den Nutzer (sub, email, aud, iss, exp) und gehören in den Client, nicht in API-Aufrufe. Mehr Details zur Struktur und Validierung von Tokens finden sich im Eintrag zu Token.

Access Token können als undurchsichtige Referenzen (Opaque Tokens) oder als JWT ausgegeben werden. JWTs erlauben eine lokale Validierung in der API ohne Rückfrage beim Authorization Server, erfordern aber sorgfältige Prüfung von Signatur, Aussteller, Audience und Ablaufzeit. Fehlt eine dieser Prüfungen, akzeptiert die API auch Token aus fremden Mandanten — ein Klassiker bei Schnellintegrationen.

OpenID Connect als Identitätsschicht

OIDC fügt zu OAuth den openid-Scope, das ID Token, einen Discovery-Endpunkt (/.well-known/openid-configuration) und Standard-Claims hinzu. Erst dadurch wird aus dem reinen Autorisierungs-Protokoll ein vollständiges Single-Sign-On-System. Wenn sich Nutzer per „Mit Microsoft anmelden" oder „Mit Google anmelden" bei einer Drittanwendung einloggen, läuft im Hintergrund OIDC. Innerhalb von Unternehmen ist OIDC der bevorzugte Weg, neue Anwendungen an einen zentralen Identity Provider anzubinden — moderner und schlanker als das ältere SAML, das nach wie vor in vielen On-Prem-Szenarien dominiert.

Sicherheitsfallen

OAuth und OIDC sind robust, wenn sie korrekt implementiert werden. Wir finden in Assessments aber regelmäßig dieselben Schwachstellen. Redirect-URI-Manipulation entsteht, wenn der Authorization Server zugelassene Redirect-URIs nicht exakt prüft, sondern Wildcards oder Pfadpräfixe akzeptiert. Angreifer leiten dann den Code an einen von ihnen kontrollierten Endpunkt um. Leakage von Refresh Token aus Browser-Storage oder Logfiles ist besonders gefährlich, weil Refresh Token meist tagelang oder wochenlang gültig sind — eine konsequente Rotation und Bindung an den Client (Refresh Token Rotation, Sender Constrained Tokens via DPoP oder mTLS) entschärft das.

JWT-Validierung scheitert in der Praxis an drei Punkten: fehlende oder falsche Prüfung des Audience-Claims (aud), Vertrauen in den alg-Header des Tokens (Stichwort alg: none) und das Übersehen der Schlüsselrotation aus dem JWKS-Endpunkt. Consent-Phishing oder „Illicit Consent Grant"-Angriffe nutzen den OAuth-Zustimmungsdialog selbst als Angriffsweg: Der Angreifer registriert eine bösartige App im Tenant des Opfers oder als Multi-Tenant-App, schickt einen täuschend echten Consent-Link und erhält nach Zustimmung dauerhaft Zugriff auf Mail, Kalender oder Dateien — ohne dass je ein Passwort kompromittiert wurde. Microsoft dokumentiert das unter dem Begriff „Application Consent Phishing".

Enterprise-Kontext

In Microsoft-365-Umgebungen läuft praktisch jeder moderne Login über OIDC gegen Entra ID. App-Registrierungen definieren, welche Scopes und API-Permissions eine Anwendung anfordern darf, und Administratoren entscheiden über Consent. Hier setzen drei Härtungsmaßnahmen an, die wir in der Praxis empfehlen: User-Consent für riskante Permissions deaktivieren und auf Admin-Consent-Workflows umstellen, Verified-Publisher und Application-Risk-Score in den Conditional-Access-Richtlinien berücksichtigen und Conditional Access konsequent mit MFA auf alle OAuth-Anmeldungen anwenden — auch auf Service Principals, sofern Workload Identity Conditional Access lizenziert ist.

Für API-Zugriffe in KI-Architekturen — etwa wenn ein AI Gateway im Namen eines Nutzers auf Backend-Systeme zugreift — ist der korrekte Umgang mit Token-Weitergabe (On-Behalf-Of-Flow in Entra ID, Token Exchange nach RFC 8693) entscheidend, um nicht versehentlich die Privilegien zu eskalieren.

Relevanz für KMUs

In der Praxis treffen wir bei mittelständischen Unternehmen oft auf eine Mischung aus modernen OIDC-Anbindungen für SaaS-Anwendungen und Eigenentwicklungen, die OAuth nur halb korrekt implementieren — etwa mit Implicit Flow, ungeprüften JWT-Signaturen oder zu großzügig vergebenen Scopes. Der wirksamste Hebel ist meist nicht ein neues Tool, sondern eine Bestandsaufnahme: Welche App-Registrierungen existieren im Tenant, welche Permissions haben sie, wer hat sie genehmigt? Eine konsequent gepflegte Liste, der Wechsel auf Admin-Consent für sensible Berechtigungen und das Deaktivieren ungenutzter Service Principals reduzieren die Angriffsfläche erheblich — ohne Lizenzkosten und ohne Eingriff in den laufenden Betrieb.