OAuth 2.0

Die wichtigsten Befehle zum Merken

• curl --fail --silent --show-error — Servermetadaten laden und HTTP-Fehler melden.
• jq — die benötigten Protokollfelder auswählen.

Befehle und Optionen

Befehl oder Option	Bedeutung
curl --fail	HTTP-Antworten ab 400 als Fehler behandeln.
--silent --show-error	Fortschritt ausblenden, Fehlermeldungen behalten.
--max-time 10	Die Übertragung auf zehn Sekunden begrenzen.
jq '{…}'	Ein Objekt mit den benannten JSON-Feldern ausgeben.
|	Den Antwortinhalt von curl an jq weitergeben.

Die URL liefert öffentliche Discovery-Metadaten. Die Anfrage enthält keine Zugangsdaten. Fehlende Felder erscheinen als null; allein daraus folgt keine fehlende Unterstützung.

Die entscheidenden Konzepte

1. OAuth delegiert Zugriff

Eine Kalenderanwendung möchte deinen Kalender bei einem anderen Dienst lesen. OAuth ermöglicht begrenzten API-Zugriff, ohne dass die Anwendung dein Kontopasswort erhält.

Der Client fordert Zugriff an, der Authorization Server stellt Tokens aus, der Resource Server betreibt die geschützte API. Ein Mensch kann als Ressourceninhaber delegierten Zugriff genehmigen. Diese Rollen können auch innerhalb eines Unternehmens getrennte Dienste sein.

2. Ein Authorization Code wird gegen Tokens getauscht

Beim Authorization Code Flow besucht der Browser den Authorization Server. Nach den nötigen Authentifizierungs- und Autorisierungsentscheidungen kehrt er mit einem kurzlebigen Code zu einer registrierten Redirect-URI zurück. Der Client tauscht diesen am Token-Endpunkt ein.

PKCE bindet den Austausch an einen geheim gehaltenen Verifier des initiierenden Clients. Ein abgefangener Code allein reicht nicht. Öffentliche Clients können kein gemeinsames Client-Geheimnis zuverlässig schützen; vertrauliche Clients können sich zusätzlich authentifizieren. Für den vollständigen Ablauf eignet sich eine gepflegte Protokollbibliothek.

3. Tokens haben Zweck und Empfänger

Ein Access Token wird einer API vorgelegt. Zielgruppe, erteilte Berechtigungen, Ablaufzeit und weitere anwendbare Prüfungen begrenzen die Akzeptanz. Ein Token für eine API ist keine universelle Berechtigung für alle APIs.

Ein gegebenenfalls ausgestelltes Refresh Token beschafft unter den Regeln des Servers neue Access Tokens. Es gehört zum Authorization Server, nicht in normale API-Aufrufe. Access Tokens müssen keine JWTs sein: Das Format ist eine separate Entscheidung.

4. Zugriff unterscheidet sich von Anmeldung

OAuth beschreibt den Zugriff eines Clients auf eine Ressource aufgrund einer Autorisierung. Es definiert allein keine standardisierte Identitätsaussage für die Anmeldung eines Menschen beim Client. Diese Authentifizierungsschicht ergänzt OpenID Connect.

Ein erfolgreich empfangenes Access Token rechtfertigt deshalb nicht, beliebige Token-Felder als geprüfte Benutzeridentität zu übernehmen. API und Client haben unterschiedliche Prüfpflichten.

Ein kleines Beispiel

Optional: Untersuche Microsofts öffentliches Discovery-Dokument mit OAuth- und OpenID-Connect-Angaben. Konto, App-Registrierung und Token sind nicht erforderlich.

curl --fail --silent --show-error --max-time 10 https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration | jq '{authorization_endpoint, token_endpoint, grant_types_supported, code_challenge_methods_supported}'

Vergleiche authorization_endpoint und token_endpoint: Der erste unterstützt die Autorisierung im Browser, der zweite den Token-Austausch. Prüfe gegebenenfalls aufgeführte Grants und PKCE-Methoden. Beworbene Fähigkeiten sind keine automatische Freigabe für jeden registrierten Client.

common ist Microsofts mandantenübergreifender Einstieg. Das Beispiel wählt keinen Mandanten, registriert keine Redirect-URI, führt kein PKCE aus und beschafft kein Token. Erfolgreiches JSON belegt nur das Abrufen und Untersuchen der Konfiguration.

Merke dir: OAuth gibt einem Client begrenzten API-Zugriff. Ob ein Token akzeptiert wird, bestimmen die Prüfregeln des empfangenden Dienstes.