OAuth 2.0: Was es ist und wie das Autorisierungsprotokoll funktioniert

Was ist OAuth 2.0?

OAuth 2.0 ist ein in IETF RFC 6749 definiertes Autorisierungsprotokoll, das Drittanwendungen eingeschränkten Zugriff auf die Ressourcen eines Benutzers ermöglicht, ohne dessen Benutzernamen und Passwort preiszugeben. Das Protokoll löst ein grundlegendes Problem des Passwortmodells: Eine Anwendung, der Sie Ihr Passwort anvertrauen, erhält uneingeschränkten Zugriff auf alle Kontodaten. OAuth 2.0 ersetzt diesen Ansatz durch die Ausstellung eines temporären Tokens mit einem explizit eingeschränkten Zugriffsbereich.

Die Architektur von OAuth 2.0 ist die delegierte Autorisierung. Der Benutzer (Resource Owner) autorisiert eine Anwendung (Client) zum Zugriff auf seine auf einem Ressourcenserver (Resource Server) gespeicherten Daten über einen Vermittler: den Autorisierungsserver (Authorization Server). Der Autorisierungsserver stellt einen Access Token aus – eine kryptografische Zeichenfolge, die die Anwendung dem Ressourcenserver vorlegt, um auf Daten zuzugreifen. Ein wichtiger Unterschied zwischen OAuth 2.0 und SAML oder OpenID Connect: OAuth 2.0 löst die Autorisierungsaufgabe (was ist erlaubt), nicht die Authentifizierung (wer ist der Benutzer). Für die Authentifizierung auf OAuth 2.0 wird das OpenID Connect (OIDC)-Protokoll aufgebaut.

Das Protokoll wird von allen großen Plattformen unterstützt. Google verwendet OAuth 2.0 für den Zugriff auf Google APIs (Gmail, Drive, Calendar), Facebook für die Graph API, Apple für Sign in with Apple (ASAuthorizationAppleIDProvider) und GitHub für den Repository-Zugriff. Im Kontext der mobilen Entwicklung ist OAuth 2.0 der Standardmechanismus zur Integration von Drittanbieterdiensten: Login über soziale Netzwerke, Zugriff auf Cloud-Speicher und Veröffentlichung von Inhalten im Namen des Benutzers.

Rollen und Komponenten von OAuth 2.0

Das OAuth 2.0-Protokoll definiert vier Rollen, deren Zusammenspiel den vollständigen Autorisierungszyklus bildet. Das Verständnis jeder Rolle ist für die korrekte Implementierung des Protokolls in einer mobilen Anwendung unerlässlich.

Die vier Rollen des Protokolls

Die Schlüsselelemente des Protokolls sind der Access Token, der Refresh Token und der Authorization Code. Der Access Token ist ein kurzlebiger Token (normalerweise 15–60 Minuten), der bei jeder Datenanfrage dem Ressourcenserver vorgelegt wird. Der Refresh Token ist ein langlebiger Token (Tage oder Wochen), der verwendet wird, um einen neuen Access Token zu erhalten, ohne dass sich der Benutzer erneut anmelden muss. Der Authorization Code ist ein temporärer Code, der nach der Benutzerautorisierung ausgestellt und gegen einen Access Token und Refresh Token eingetauscht wird.

Grant Types: Autorisierungsszenarien

OAuth 2.0 definiert mehrere Grant Types – Token-Erhaltsszenarien, die jeweils für einen bestimmten Client-Typ und Sicherheitskontext ausgelegt sind. Die Wahl des richtigen Grant Types ist eine kritische Architekturentscheidung beim Entwurf der Autorisierung in einer mobilen Anwendung.

Die wichtigsten Grant Types sind: Authorization Code (der sicherste für mobile und Webanwendungen mit einer Serverkomponente), Authorization Code mit PKCE (Proof Key for Code Exchange – für mobile und SPA-Anwendungen ohne Server-Backend), Client Credentials (für Server-zu-Server-Authentifizierung ohne Benutzerbeteiligung) und Resource Owner Password Credentials (veraltet – überträgt das Passwort direkt). PKCE ist eine obligatorische Erweiterung für öffentliche Clients (mobile Anwendungen, SPAs) gemäß den Empfehlungen des OAuth Security BCP (RFC 9700).

Wichtigste Grant Types

• Authorization Code + PKCE ist der empfohlene Grant Type für native mobile Anwendungen. Der Client generiert einen kryptografischen code_verifier, berechnet einen code_challenge (SHA-256-Hash) und der Server überprüft die Übereinstimmung beim Austausch des Codes gegen einen Token. Dies verhindert das Abfangen des authorization codes zwischen der Anwendung und dem Server
• Client Credentials wird für die Maschine-zu-Maschine-Autorisierung verwendet, bei der der Client bekannt und authentifiziert ist. Die Anwendung erhält einen Token unter Verwendung ihrer client_id und ihres client_secret. Keine Benutzerbeteiligung erforderlich. Typisches Szenario: Eine Serveranwendung ruft eine API zur Batch-Datenverarbeitung auf
• Device Authorization Grant ist für Geräte ohne Browser (Smart TV, IoT) gedacht. Der Benutzer folgt einem Link auf einem anderen Gerät und gibt einen Code ein. Wird zum Beispiel bei der Autorisierung von Netflix auf einem Fernseher über ein Smartphone verwendet
• Resource Owner Password Credentials ist ein veralteter Grant Type, der durch OAuth Security BCP verboten ist. Das Passwort wird direkt an den Client übertragen, was gegen das Prinzip der Zero-Knowledge-Authentifizierung verstößt. Wird nur für die Migration von Legacy-Systemen verwendet

Authorization Code Flow mit PKCE für mobile Anwendungen

Authorization Code Flow mit PKCE ist die empfohlene OAuth 2.0-Konfiguration für native mobile Anwendungen. PKCE (Proof Key for Code Exchange) fügt eine zusätzliche Schutzschicht hinzu, die Angriffe durch das Abfangen von authorization codes verhindert. Das Protokoll ist in IETF RFC 7636 beschrieben.

Schritt-für-Schritt-Ablauf von PKCE

Die Schritte im Ablauf: (1) Der Client generiert einen zufälligen code_verifier (eine Zeichenfolge von 43–128 Zeichen, die nur nicht reservierte Zeichen verwendet), (2) der Client berechnet code_challenge = SHA-256(code_verifier), (3) der Client öffnet einen Browser zur Benutzerautorisierung auf dem Authorization Server und übergibt code_challenge, (4) nach erfolgreicher Autorisierung gibt der Server den authorization code über ein benutzerdefiniertes URI-Schema (App-Deep-Link) an die Anwendung zurück, (5) der Client sendet authorization code + code_verifier an den Server, (6) der Server überprüft SHA-256(code_verifier) === code_challenge und stellt einen Access Token + Refresh Token aus.

Der Vorteil von PKCE: Selbst wenn ein Angreifer den authorization code im URI-Schema abfängt, kann er ihn ohne den code_verifier, der nur dem legitimen Client bekannt ist, nicht gegen einen Token eintauschen. In mobilen Anwendungen sollten zum Öffnen des Browsers Chrome Custom Tabs (Android) oder ASWebAuthenticationSession (iOS) verwendet werden – dies stellt sicher, dass der Systembrowser nicht auf den code_verifier aus dem Speicher der Anwendung zugreifen kann.

Implementierung von OAuth 2.0 auf Android über AppAuth

AppAuth ist die Referenzimplementierung von OAuth 2.0 und OpenID Connect für native Anwendungen, empfohlen von der IETF. Die Bibliothek unterstützt PKCE, Chrome Custom Tabs, benutzerdefinierte URI-Schemata für die Rückgabe des authorization codes und automatische Token-Aktualisierung. AppAuth für Android ist über die Abhängigkeit `net.openid:appauth:0.11.1` verfügbar.

val serviceConfig = AuthorizationServiceConfiguration.fromUrl(
    Uri.parse("https://accounts.google.com/.well-known/openid-configuration")
)

val request = AuthorizationRequest.Builder(
    serviceConfig,
    "CLIENT_ID.apps.googleusercontent.com",
    ResponseTypeValues.CODE,
    Uri.parse("com.example.app:/oauth2callback")
)
.setScope("openid profile email")
.setCodeVerifier(
    CodeVerifierUtil.generateRandomCodeVerifier()
)
.build()

val authService = AuthorizationService(context)
val intent = authService.getAuthorizationRequestIntent(request)

// Chrome Custom Tab zur Autorisierung starten
startActivityForResult(intent, REQUEST_CODE_AUTH)

Nach dem Erhalt des authorization codes (onActivityResult) tauscht die Anwendung ihn über einen TokenRequest gegen einen Access Token und Refresh Token aus. Die Tokens werden in SharedPreferences mit Verschlüsselung über EncryptedSharedPreferences (Android Security Crypto) gespeichert. Der Refresh Token sollte im KeyStore gespeichert werden – einem hardwarebasierten Schlüsselspeicher, der für andere Anwendungen nicht zugänglich ist. Bei jedem Ablauf des Access Tokens verwendet die Anwendung den Refresh Token, um einen neuen zu erhalten – der Benutzer muss sich nicht erneut authentifizieren.

// Authorization Code gegen Tokens eintauschen
val data = intent?.data ?: return
val resp = AuthorizationResponse.fromIntent(data)
val exchangeReq = resp?.createTokenExchangeRequest()
    ?: return

authService.performTokenRequest(
    exchangeReq,
    ClientAuthentication.none()
) { tokenResp, ex ->
    if (tokenResp != null) {
        // Access Token und Refresh Token erhalten
        val accessToken = tokenResp.accessToken
        val refreshToken = tokenResp.refreshToken
        // In EncryptedSharedPreferences speichern
        saveTokens(accessToken, refreshToken)
    }
}

Der obige Code demonstriert den vollständigen OAuth 2.0-Ablauf mit PKCE: Erstellung der Serverkonfiguration über OpenID Connect Discovery, Generierung einer Autorisierungsanfrage mit code_verifier, Start von Chrome Custom Tab, Empfang des authorization codes über ein benutzerdefiniertes URI-Schema und Austausch des Codes gegen Tokens über einen Token Request. Es ist wichtig, den Ablauf des Access Tokens zu behandeln: Beim Erhalt einer HTTP-401-Antwort vom Resource Server sollte die Anwendung den Refresh Token verwenden, um einen neuen Access Token zu erhalten, und die Anfrage erneut ausführen.

OAuth 2.0-Sicherheit: Typische Angriffe und Schutz

OAuth 2.0 ist ein komplexes Protokoll mit vielen Angriffsvektoren. Das IETF Security BCP (RFC 9700) beschreibt über 20 Klassen von OAuth 2.0-Schwachstellen. Für mobile Anwendungen sind die kritischsten: Abfangen von authorization codes über benutzerdefinierte URI-Schemata, CSRF-Angriffe auf Callback-Endpunkte, Diebstahl von Refresh Tokens aus unsicheren Speichern und Client-Identitätsdiebstahl durch Intent-Abfangen.

Der Schutz vor diesen Angriffen umfasst obligatorische Maßnahmen: (1) PKCE mit S256 code_challenge – verhindert das Abfangen von authorization codes selbst bei Abfangen des URI-Schemas; (2) Verwendung eines nonce- oder state-Parameters zur Verhinderung von CSRF – der Server überprüft, ob der authorization code der ursprünglichen Anfrage entspricht; (3) Speicherung des Refresh Tokens nur im KeyStore (Android) oder Keychain (iOS) – niemals in SharedPreferences oder UserDefaults; (4) Verwendung von TLS mit Certificate Pinning zum Schutz vor MITM auf der Transportschicht; (5) Validierung der redirect_uri – der Autorisierungsserver muss streng auf Übereinstimmung mit der registrierten URI prüfen.

Zusätzliche Empfehlungen der IETF: Mobile Anwendungen sollten AppAuth oder ähnliche Bibliotheken verwenden, die Sicherheitsaudits durchlaufen haben; sich nicht auf WebView für OAuth verlassen (WebView isoliert Daten nicht von der Hauptanwendung); automatische Refresh-Token-Rotation implementieren (jeder Refresh Token kann nur einmal verwendet werden); Certificate Pinning über TrustManager für Android und URLSession für iOS hinzufügen. OpenID Connect Discovery (well-known-Endpunkt) hilft, die korrekten Endpunkte des Autorisierungsservers automatisch zu ermitteln und Weiterleitungen auf Phishing-Seiten zu vermeiden.