OAuth 2.0 & OpenID Connect verständlich erklärt für Webentwickler

Ob "Mit Google anmelden" oder "Über GitHub einloggen" – moderne Webanwendungen setzen flächendeckend auf OAuth 2.0. Während OAuth 2.0 die Autorisierung steuert, liefert OpenID Connect (OIDC) die dringend benötigte Identitätsebene (Authentifizierung). Wer sichere APIs und nutzerfreundliche Logins bauen möchte, kommt an diesen beiden Standards nicht vorbei.

Authentifizierung vs. Autorisierung

• Authentifizierung (AuthN): "Wer bist du?" – Es geht um den Identitätsnachweis. Dies ist die Kernaufgabe von OpenID Connect.
• Autorisierung (AuthZ): "Was darfst du tun?" – Es geht um Rechte und Freigaben. Das ist der eigentliche Bereich von OAuth 2.0.

Historisch gesehen war OAuth 2.0 nie für die Identitätsprüfung gedacht. Es sollte lediglich Drittanbieter-Apps Zugriff auf bestimmte Ressourcen (wie Google Drive Dateien) gewähren, ohne dass das Master-Passwort geteilt werden muss. Erst mit OpenID Connect entstand ein standardisierter Identitäts-Layer auf Basis von JSON Web Tokens (JWT).

Die wichtigsten Akteure im Ablauf

• Ressourcen-Besitzer (Resource Owner): Der Endnutzer, dem die Daten gehören (z. B. Ihr App-User).
• Client: Die Anwendung (Ihre Web- oder Mobile-App), die Zugriff anfordert.
• Autorisierungsserver (Authorization Server): Die Instanz, die den User validiert und Token ausstellt (z. B. Keycloak, Auth0, Google oder GitHub).
• Ressourcen-Server (Resource Server): Die API, die die geschützten Daten bereitstellt (z. B. die Google Calendar API).

Authorization Code Flow (mit PKCE)

Der empfohlene Standard-Ablauf für moderne Webanwendungen und Single-Page-Apps (SPAs). PKCE (Proof Key for Code Exchange) schützt den Authorization Code vor Abfangangriffen und ist heute für nahezu alle Setups Pflicht.

1. Nutzer klickt in Ihrer App auf "Mit Google anmelden"
2. Ihre App leitet den User zum Autorisierungs-Endpunkt weiter:
   GET https://accounts.google.com/o/oauth2/v2/auth?
     response_type=code
     &client_id=YOUR_CLIENT_ID
     &redirect_uri=https://yourapp.com/callback
     &scope=openid email profile
     &state=random_csrf_token
     &code_challenge=SHA256_HASH
     &code_challenge_method=S256

3. Nutzer authentifiziert sich bei Google und bestätigt die Rechtefreigabe
4. Google leitet zurück zur Redirect-URI mit einem temporären Code:
   GET https://yourapp.com/callback?code=AUTH_CODE&state=random_csrf_token

5. Ihr Server tauscht den Code gegen die tatsächlichen Token ein:
   POST https://oauth2.googleapis.com/token
   Body: {
     code: AUTH_CODE,
     client_id: YOUR_CLIENT_ID,
     client_secret: YOUR_CLIENT_SECRET,
     redirect_uri: https://yourapp.com/callback,
     grant_type: authorization_code,
     code_verifier: ORIGINAL_RANDOM_STRING
   }

6. Google antwortet mit den Token-Daten:
   {
     "access_token": "ya29.a0...",
     "id_token": "eyJhbGci...",       // OpenID Connect Standard
     "refresh_token": "1//0e...",
     "expires_in": 3600,
     "token_type": "Bearer"
   }

Token-Typen verstehen

• Access Token (Zugriffstoken): Kurzlebig (meist 1 Stunde). Ermöglicht API-Aufrufe im Namen des Nutzers über den Header Authorization: Bearer <token>.
• Refresh Token (Aktualisierungstoken): Langlebig. Dient dazu, neue Access-Token ohne erneute Nutzerinteraktion anzufordern. Extrem sicher aufbewahren (nur serverseitig, niemals im localStorage!).
• ID Token: Ein JSON Web Token (JWT), das Nutzerdaten (wie E-Mail-Adresse und Profilbild) enthält. Dies ist das OIDC-spezifische Element.

Scopes (Berechtigungsbereiche)

Scopes legen fest, worauf Ihre App zugreifen möchte. Diese Berechtigungen werden dem Nutzer auf der Einverständnisseite explizit angezeigt.

// OpenID Connect Scopes
openid        // Erforderlich für OIDC
email         // E-Mail-Adresse des Nutzers
profile       // Name, Profilbild, Spracheinstellung

// Google-spezifische Scopes
https://www.googleapis.com/auth/drive.readonly
https://www.googleapis.com/auth/calendar

// GitHub-Scopes
read:user     // Benutzerprofil auslesen
repo          // Vollzugriff auf Repositories
read:org      // Organisationszugehörigkeit prüfen

Best Practices für maximale Sicherheit

• Nutzen Sie konsequent PKCE – nicht nur für Mobile- oder SPA-Anwendungen, sondern auch für klassische Server-Side-Apps.
• Prüfen Sie den state-Parameter penibel, um Cross-Site Request Forgery (CSRF) effektiv zu unterbinden.
• Keine Tokens im LocalStorage speichern. Verwenden Sie stattdessen HTTP-only, Secure und SameSite-Cookies für maximale Sicherheit vor XSS.
• Validieren Sie ID-Tokens serverseitig – kontrollieren Sie Issuer (Aussteller), Audience (Zielgruppe), Signatur und Ablaufzeit.
• Das Prinzip des "Least Privilege" – fordern Sie immer nur die absolut notwendigen Scopes an.
• Setzen Sie auf Refresh-Token-Rotation, um kompromittierte Tokens sofort unwirksam zu machen.

Wann nutzt man welchen Grant Type?

• Authorization Code + PKCE: Die Standardwahl für Web-Apps, SPAs und native Mobile-Apps.
• Client Credentials: Für reine Server-zu-Server-Kommunikation ohne direkten Benutzerkontext.
• Device Code: Für Geräte mit eingeschränkter Eingabemöglichkeit (z. B. Smart-TVs oder CLI-Tools).
• ⚠️ Implicit Flow: Veraltet und unsicher. Nutzen Sie diesen Flow keinesfalls für neue Projekte!