OAuth 2.0

OAuth 2.0 ist ein Autorisierungsframework, das Drittanbieter-Anwendungen begrenzten Zugriff auf Benutzerkonten ermöglicht - ohne dass der User sein Passwort teilen muss. Bekannt durch "Login mit Google", "Mit Facebook anmelden" oder "GitHub-Autorisierung". Der User authentifiziert sich beim Provider (Google), der dann einen Token an die Anwendung ausstellt.

Der OAuth-Flow: User klickt "Login mit Google" → Weiterleitung zu Google → User gibt Berechtigungen → Google leitet zurück mit Authorization Code → Backend tauscht Code gegen Access Token → Zugriff auf User-Daten (Name, Email, Profilbild). Der User gibt nie sein Google-Passwort an die App weiter. Berechtigungen sind granular - nur Zugriff auf freigegebene Daten.

OAuth löst zwei Probleme: Benutzer müssen keine weiteren Passwörter erstellen/merken, und Anwendungen bekommen keinen Vollzugriff auf Accounts. OpenID Connect (OIDC) erweitert OAuth um Authentifizierung (wer ist der User?) zusätzlich zur Autorisierung (was darf der User?). Für Web-Apps ist Social Login via OAuth/OIDC Standard - erhöht Conversion bei Registrierung um bis zu 50%.

OAuth 2.0 kennt mehrere Grant-Types für unterschiedliche Anwendungstypen. Für Web- und Mobile-Apps ist heute der Authorization Code Flow mit PKCE (Proof Key for Code Exchange) Standard: Die App erzeugt einen zufälligen Code-Verifier, schickt dessen Hash mit und beweist beim Token-Tausch den Besitz - das verhindert das Abfangen des Authorization Codes. Der ältere Implicit Flow gilt als unsicher und wird nicht mehr empfohlen. Der Client Credentials Flow dient dagegen der Server-zu-Server-Kommunikation ohne beteiligten Nutzer.

Wichtig ist die begriffliche Trennung: OAuth 2.0 regelt Autorisierung (Zugriff auf Ressourcen), nicht Authentifizierung (wer ist der Nutzer). Erst OpenID Connect (OIDC) ergänzt OAuth um ein signiertes ID-Token (ein JWT mit Nutzeridentität) und standardisierte Endpunkte wie /userinfo - deshalb basiert nahezu jedes moderne Single Sign-On auf OIDC, nicht auf reinem OAuth. Der Zugriff wird über Scopes granular begrenzt (etwa email oder profile), der Access-Token hat eine kurze Lebensdauer, während ein Refresh-Token die Sitzung verlängert. Ein verbreiteter Fehler ist, das Access-Token als Identitätsnachweis zu missbrauchen; für Login-Zwecke ist ausschließlich das validierte ID-Token gedacht. In der Praxis nimmt einem ein Identity-Provider wie Auth0, Keycloak oder Supabase Auth die fehleranfällige Implementierung dieser Flows weitgehend ab.