OAuth 2.0

OAuth 2.0 ist ein Framework für delegierte Autorisierung. Statt einer App Ihr Passwort zu geben, genehmigen Sie eine Anfrage bei einem Autorisierungsserver, der der App ein Access Token ausstellt, das über den Scope (zum Beispiel orders:read) und zeitlich begrenzt ist. Die App sendet dieses Token an die API, meist als Authorization: Bearer <token>. Die vier Rollen sind der Resource Owner (der Nutzer), der Client (die App), der Authorization Server (stellt Tokens aus) und der Resource Server (die API).

Authentifizierung versus Autorisierung

Authentifizierung beantwortet die Frage „Wer sind Sie?“. Autorisierung beantwortet „Was dürfen Sie tun?“. OAuth 2.0 allein regelt die Autorisierung: Ein Access Token sagt aus, worauf der Inhaber zugreifen darf, aber nicht verlässlich, wer der Nutzer ist. Das Anmelden von Nutzern ist Aufgabe von OpenID Connect, einer Schicht über OAuth 2.0, die ein ID-Token (ein JWT) mit Angaben zum Nutzer ergänzt. Buttons wie „Anmelden mit …“ verwenden OpenID Connect.

Gängige Grant Types

• Authorization Code mit PKCE: für Apps, die im Namen eines Nutzers handeln, einschließlich Browser- und Mobile-Apps. Der Nutzer meldet sich beim Autorisierungsserver an, die App erhält einen kurzlebigen Code und tauscht ihn gegen Tokens.
• Client Credentials: für Service-zu-Service-Aufrufe ohne Nutzer. Diesen Flow verwenden API-Testsuites am häufigsten.
• Refresh Token: tauscht ein langlebiges Refresh Token gegen ein neues Access Token.

Die Grant Types Implicit und Resource Owner Password werden von den aktuellen OAuth-Sicherheitsempfehlungen nicht mehr empfohlen und sind im Entwurf von OAuth 2.1 entfallen.

Beispiel: Client Credentials

curl -X POST https://auth.example.com/oauth/token \
  -d grant_type=client_credentials \
  -d client_id="$CLIENT_ID" \
  -d client_secret="$CLIENT_SECRET" \
  -d scope=orders:read

Die Antwort enthält ein access_token, einen token_type mit dem Wert Bearer und ein expires_in in Sekunden. Holen Sie das Token einmal in einer Fixture, cachen Sie es, bis es kurz vor dem Ablauf steht, und bewahren Sie Client Secrets in den CI-Secrets auf statt im Repository.

Was Sie testen sollten

• Ein fehlendes, abgelaufenes oder fehlerhaftes Token liefert 401.
• Ein gültiges Token ohne den erforderlichen Scope liefert 403.
• Tokens, die für eine andere Audience oder einen anderen Client ausgestellt wurden, werden abgelehnt.
• Im Authorization Code Flow wird der state-Parameter geprüft, und die Redirect-URI muss exakt mit einem registrierten Wert übereinstimmen.
• Token-Antworten und Redirects legen Tokens niemals in Logs oder URLs offen.