Was sind OAuth 2.0 und OpenID Connect?

OAuth 2.0 ist ein Framework für delegierte Autorisierung: Eine Anwendung erhält begrenzten Zugriff auf Ressourcen, ohne das Passwort des Nutzers zu erfahren. OpenID Connect (OIDC) ergänzt OAuth um eine standardisierte Identitätsschicht für Anmeldung und Single Sign-on. Die Begriffe werden häufig vermischt, erfüllen aber unterschiedliche Aufgaben.

Was unterscheidet OAuth und OpenID Connect?

Ein Access Token ist für eine API bestimmt und keine allgemeine Identitätsbestätigung. OIDC liefert dafür ein ID Token und definierte Claims. Ein ID Token wiederum sollte nicht anstelle eines Access Tokens für beliebige API-Zugriffe genutzt werden.

Welche Rollen und Tokens gibt es?

Der Resource Owner ist meist der Nutzer. Der Client fordert Zugriff an, der Authorization Server authentifiziert und stellt Tokens aus, der Resource Server schützt die API. Access Tokens tragen Berechtigungen und Zielgruppe; Refresh Tokens beschaffen neue Access Tokens. OIDC ergänzt ID Token, UserInfo-Endpunkt, Discovery-Metadaten und den nonce-Mechanismus. Tokens können JWTs sein, müssen es aber nicht.

Wie läuft der Authorization Code Flow ab?

1. Der Client leitet den Browser mit Client-ID, Redirect URI, Scope, state und gegebenenfalls nonce zum Authorization Server.
2. Der Nutzer authentifiziert sich und stimmt den angeforderten Rechten zu.
3. Der Browser erhält einen kurzlebigen Code an der exakt registrierten Redirect URI.
4. Der Client tauscht den Code am Token-Endpunkt gegen Tokens; PKCE bindet den Code an den ursprünglichen Client.
5. Der Client prüft Token und Claims und verwendet das Access Token nur beim vorgesehenen Resource Server.

Welche Schwachstellen treten auf?

• Ungenaue Redirect-URI-Prüfung leitet Codes oder Tokens an Angreifer weiter.
• Fehlendes oder falsch gebundenes state ermöglicht Login-CSRF und Account-Verknüpfungen.
• Fehlendes PKCE erlaubt gestohlene Authorization Codes bei ungeeigneten Clients.
• Issuer, Audience, Signatur, nonce oder Token-Typ werden nicht vollständig validiert.
• Zu breite Scopes, lange Tokens oder ungeschützte Refresh Tokens vergrößern Auswirkungen.
• Konten werden allein anhand einer nicht verifizierten E-Mail-Adresse zusammengeführt.

Wie wird die Implementierung abgesichert?

Neue Clients sollten Authorization Code mit PKCE verwenden. Redirect URIs werden vollständig und vorab registriert, Tokens über sichere Backchannels übertragen und nicht in URLs protokolliert. state schützt die Transaktion, OIDC-nonce bindet das ID Token. Nur notwendige Scopes werden angefordert. Bibliotheken und vertrauenswürdige Discovery-Metadaten reduzieren Eigenimplementierungen, ersetzen aber keine sichere Konfiguration.

Ablaufbeispiel: State und PKCE an dieselbe Sitzung binden

state = randomBytes(32)
verifier = randomBytes(32)
challenge = base64url(sha256(verifier))

session.store('oauth_state', state)
session.store('pkce_verifier', verifier)

redirectToAuthorizationServer({
  response_type: 'code',
  state: state,
  code_challenge: challenge,
  code_challenge_method: 'S256'
})

if callback.state != session.take('oauth_state'):
    rejectLogin()

tokens = exchangeCode(callback.code, {
  code_verifier: session.take('pkce_verifier'),
  redirect_uri: EXACT_REGISTERED_URI
})

Die Werte sind zufällig, einmalig, kurzlebig und gehören zur konkreten Browser-Sitzung. Beim OIDC-Login kommt zusätzlich ein nonce hinzu, der nach der Signaturprüfung mit dem Claim im ID Token verglichen wird.

Was wird bei einem Sicherheitstest geprüft?

Ein Test betrachtet Client, Authorization Server und Resource Server als zusammenhängenden Ablauf. Untersucht werden Redirect-Manipulation, CSRF-Bindung, PKCE, Token-Verwechslung, Claim-Validierung, Scope-Eskalation, Konto-Verknüpfung, Logout und Widerruf. Mehrere Benutzer und Clients sind nötig, um zu zeigen, ob Codes, Tokens oder Identitäten zwischen Sicherheitskontexten vertauscht werden können.