OAuth

OAuth (Open Authorization) ist ein offenes Standardprotokoll für die Autorisierung, das es Anwendungen ermöglicht, im Namen eines Benutzers auf geschützte Ressourcen zuzugreifen - ohne dass der Benutzer sein Passwort preisgeben muss. Stattdessen werden sogenannte Access Tokens verwendet, die einen zeitlich begrenzten und eingeschränkten Zugriff auf bestimmte Daten erlauben.

Ein alltägliches Beispiel: Du möchtest dich auf einer Webseite mit deinem Google-Konto anmelden. Anstatt der Webseite dein Google-Passwort zu verraten, leitest du sie zu Google weiter. Dort bestätigst du, welche Daten die Webseite sehen darf, und Google stellt ihr ein Token aus. Die Webseite erhält so Zugriff auf die freigegebenen Informationen, kennt aber niemals dein Passwort.

Geschichte und Entwicklung

Die Entwicklung von OAuth begann 2006, als Entwickler bei Twitter und anderen Unternehmen nach einer standardisierten Methode suchten, um Drittanbieteranwendungen sicheren API-Zugriff zu gewähren. OAuth 1.0 wurde 2007 veröffentlicht und bot erstmals eine Alternative zur direkten Passwortübergabe.

Im Oktober 2012 veröffentlichte die Internet Engineering Task Force (IETF) RFC 6749, das OAuth 2.0 als neuen Standard definiert. Diese Version war ein komplettes Redesign und nicht abwärtskompatibel zu OAuth 1.0. OAuth 2.0 ist heute der vorherrschende Standard und wird von nahezu allen großen Internetdiensten wie Google, Facebook, Microsoft, GitHub und Amazon eingesetzt.

Die vier Akteure im OAuth-Prozess

OAuth 2.0 definiert vier zentrale Rollen, die am Autorisierungsprozess beteiligt sind. Das Verständnis dieser Rollen ist entscheidend, um den Ablauf zu verstehen:

• Resource Owner (Ressourcenbesitzer): Das ist in der Regel der Benutzer, der die Kontrolle über seine Daten hat und entscheidet, wer Zugriff erhält. Du als Nutzer bist der Resource Owner.
• Resource Server (Ressourcenserver): Der Server, der die geschützten Daten hostet. Beispiel: Die Google-Server, die deine E-Mails speichern.
• Client (Anwendung): Die Drittanbieteranwendung, die auf die geschützten Ressourcen zugreifen möchte. Das könnte eine Kalender-App sein, die Zugriff auf deine Google-Termine benötigt.
• Authorization Server (Autorisierungsserver): Der Server, der die Identität des Benutzers überprüft und Access Tokens ausstellt. Bei Google ist das der Google OAuth Server.

OAuth 2.0 Grant Types (Autorisierungsabläufe)

OAuth 2.0 unterstützt verschiedene Autorisierungsabläufe, sogenannte Grant Types, die für unterschiedliche Anwendungsfälle optimiert sind. Die Wahl des richtigen Grant Types hängt vom Client-Typ und den Sicherheitsanforderungen ab.

Authorization Code Flow

Der Authorization Code Flow ist der sicherste und am häufigsten verwendete Ablauf. Er eignet sich besonders für serverseitige Webanwendungen, bei denen der Client ein Geheimnis (Client Secret) sicher speichern kann. Der Ablauf funktioniert in zwei Schritten: Erst erhält der Client einen kurzlebigen Autorisierungscode, den er dann gegen ein Access Token eintauscht.

1. Benutzer klickt "Mit Google anmelden"
2. Client leitet zu Google Authorization Server weiter
3. Benutzer meldet sich an und erteilt Berechtigung
4. Google leitet mit Autorisierungscode zurück
5. Client tauscht Code + Client Secret gegen Access Token
6. Client nutzt Access Token für API-Zugriffe

Authorization Code Flow mit PKCE

PKCE (Proof Key for Code Exchange, ausgesprochen "Pixi") ist eine Erweiterung des Authorization Code Flows für öffentliche Clients wie Mobile Apps oder Single Page Applications. Da diese Clients kein Client Secret sicher speichern können, verwendet PKCE stattdessen einen dynamisch generierten Code Verifier. Dieser wird zusammen mit dem Autorisierungscode verwendet, um Angriffe wie Code Interception zu verhindern.

Client Credentials Flow

Der Client Credentials Flow wird für Server-zu-Server-Kommunikation verwendet, wenn kein Benutzer involviert ist. Die Anwendung authentifiziert sich direkt mit ihren eigenen Zugangsdaten (Client ID und Client Secret) und erhält ein Access Token. Typische Anwendungsfälle sind Microservices, die miteinander kommunizieren, oder Batch-Jobs, die auf APIs zugreifen.

Implicit Flow (veraltet)

Der Implicit Flow wurde ursprünglich für browserbasierte Anwendungen entwickelt und liefert das Access Token direkt in der URL zurück. Dieser Flow gilt heute als veraltet und unsicher, da das Token in der Browser-Historie sichtbar wird. Stattdessen sollte der Authorization Code Flow mit PKCE verwendet werden.

Access Tokens und Refresh Tokens

Access Tokens sind die Schlüssel, mit denen Anwendungen auf geschützte Ressourcen zugreifen. Sie haben typischerweise eine kurze Gültigkeitsdauer (wenige Minuten bis Stunden), um das Risiko bei einem Diebstahl zu minimieren. Moderne Implementierungen verwenden häufig JSON Web Tokens (JWT), die Informationen über den Benutzer und die Berechtigungen direkt im Token enthalten.

Refresh Tokens ermöglichen es, neue Access Tokens zu erhalten, ohne dass der Benutzer sich erneut anmelden muss. Sie haben eine längere Gültigkeitsdauer und werden sicher auf dem Server gespeichert. Wenn ein Access Token abläuft, kann die Anwendung mit dem Refresh Token automatisch ein neues Access Token anfordern.

Scopes - Feingranulare Berechtigungen

Scopes definieren, welche Berechtigungen eine Anwendung anfordert. Anstatt vollen Zugriff auf ein Konto zu gewähren, können Benutzer gezielt einzelne Berechtigungen freigeben. Bei Google könnte eine Anwendung beispielsweise nur den Scope profile anfordern, um den Namen zu lesen, aber nicht gmail.readonly, das Zugriff auf E-Mails gewähren würde.

• openid - Grundlegende Identitätsinformationen
• profile - Name, Profilbild
• email - E-Mail-Adresse
• read:user - Lesezugriff auf Benutzerdaten (GitHub)
• repo - Vollzugriff auf Repositories (GitHub)

OAuth vs. OpenID Connect

Ein häufiges Missverständnis ist die Verwechslung von OAuth und OpenID Connect (OIDC). OAuth 2.0 ist ein Autorisierungsprotokoll - es regelt, worauf eine Anwendung zugreifen darf. OpenID Connect hingegen ist eine Authentifizierungsschicht, die auf OAuth 2.0 aufbaut und die Frage beantwortet: "Wer ist der Benutzer?"

Wenn du "Mit Google anmelden" nutzt, kommen beide Protokolle zum Einsatz: OpenID Connect authentifiziert dich und liefert ein ID Token mit deinen Profilinformationen, während OAuth 2.0 der Anwendung Zugriff auf weitere Google-Dienste gewährt.

Sicherheitsaspekte und Best Practices

Die korrekte Implementierung von OAuth 2.0 ist entscheidend für die Sicherheit. Falsche Konfigurationen können zu schwerwiegenden Sicherheitslücken führen. Beachte folgende Best Practices:

• HTTPS verwenden: Alle OAuth-Kommunikation muss über TLS verschlüsselt erfolgen
• PKCE immer nutzen: Auch bei vertraulichen Clients erhöht PKCE die Sicherheit
• State-Parameter verwenden: Schützt vor Cross-Site Request Forgery (CSRF)
• Tokens sicher speichern: Access Tokens niemals im Local Storage, sondern in HTTP-Only Cookies
• Kurze Token-Laufzeiten: Access Tokens sollten nach wenigen Minuten ablaufen
• Redirect URIs validieren: Nur vorregistrierte Redirect URIs akzeptieren
• Scopes minimieren: Nur die minimal notwendigen Berechtigungen anfordern

Praktische Einsatzgebiete

OAuth 2.0 ist heute der De-facto-Standard für API-Autorisierung und Single Sign-On (SSO) im Web. Du begegnest OAuth täglich, oft ohne es zu bemerken:

• Social Login: "Mit Google anmelden", "Mit GitHub anmelden"
• API-Zugriff: Mobile Apps, die auf Cloud-Dienste zugreifen
• Drittanbieter-Integrationen: Trello-Integration in Slack, Spotify in Discord
• Microservices: Sichere Kommunikation zwischen Backend-Diensten
• Enterprise SSO: Mitarbeiter-Login für verschiedene Unternehmensanwendungen

OAuth in der Praxis

Für Fachinformatiker im Bereich Anwendungsentwicklung ist das Verständnis von OAuth grundlegend, da moderne Webanwendungen und APIs fast ausnahmslos auf tokenbasierte Autorisierung setzen. Beliebte Frameworks wie Spring Security, Passport.js oder Auth0 bieten vorgefertigte OAuth-Implementierungen, die dir die Integration erleichtern.

Auch Systemintegratoren kommen mit OAuth in Berührung, etwa beim Einrichten von Single Sign-On-Lösungen oder der Integration von Cloud-Diensten in die Unternehmensinfrastruktur. Das Verständnis der Sicherheitsimplikationen und der korrekten Konfiguration von OAuth-Flows gehört zum Handwerkszeug moderner IT-Fachkräfte.

Quellen und weiterführende Links

• RFC 6749 - OAuth 2.0 Authorization Framework (IETF)
• OAuth 2.0 - oauth.net
• What is OAuth 2.0? - Auth0
• OpenID Connect - openid.net
• Google OAuth 2.0 - Google Developers