OAuth erklärt: Rollen, der PKCE-Flow und OAuth vs. SAML
OAuth erklärt
Was ist OAuth? Rollen, PKCE-Flow, OAuth vs. SAML vs. OIDC | We.Inc
OAuth 2.0 einfach erklärt: vier Rollen, der Authorization Code Flow mit PKCE Schritt für Schritt, Scopes und wie sich OAuth von OpenID Connect und SAML unterscheidet.
OAuth 2.0 ist ein Standard, mit dem eine App in deinem Namen bei einem anderen Dienst handeln kann, ohne jemals dein Passwort zu sehen. Du bestätigst eine Anfrage auf der Anmeldeseite des Dienstes selbst, und die App erhält ein Access Token, das auf die Scopes beschränkt ist, denen du zugestimmt hast. OAuth regelt die Autorisierung; OpenID Connect ergänzt die Anmeldung.
OAuth 2.0 vs. OpenID Connect vs. SAML 2.0
OAuth 2.0
OpenID Connect
SAML 2.0
Beantwortet
Worauf darf diese App zugreifen?
Wer ist dieser Nutzer?
Wer ist dieser Nutzer?
Zentrales Artefakt
Access Token
ID Token (ein JWT) plus Access Token
XML-Assertion
Spezifikation
RFC 6749 (IETF)
OpenID Connect Core 1.0
OASIS SAML 2.0
Beteiligte
Client, Autorisierungsserver, Ressourcenserver
Relying Party, OpenID Provider
Service Provider, Identity Provider
Typischer Einsatz
API-Zugriff, "Konto verbinden"
"Anmelden mit"-Buttons, Login für Mobile Apps und SPAs
Single Sign-on am Arbeitsplatz
Vor OAuth bedeutete das Verbinden zweier Dienste oft, das Passwort des einen im anderen einzugeben. OAuth hat das durch kurzlebige Tokens mit eng begrenzten Berechtigungen ersetzt, die erst nach deiner Zustimmung ausgestellt werden. Der Generator unten erzeugt in deinem Browser einen echten PKCE-Verifier samt Challenge und baut die Autorisierungs-URL, sodass du jeden Parameter siehst, den der Flow verwendet.
Die App erzeugt einen zufälligen code_verifier, hasht ihn zu einer code_challenge und schickt dich mit dieser Challenge, ihrer client_id, den Scopes und einem state-Wert zum Autorisierungsserver.
Du meldest dich auf der Seite des Autorisierungsservers an und bestätigst die Scopes.
Der Server leitet mit einem kurzlebigen Autorisierungscode und demselben state zurück an die redirect_uri der App.
Die App prüft state und sendet dann den Code und den ursprünglichen code_verifier per POST an den Token-Endpunkt.
Der Server hasht den Verifier, gleicht ihn mit der gespeicherten Challenge ab und gibt ein Access Token zurück, das die App an die API sendet.
Verwende den Authorization Code Flow mit PKCE gleichermaßen für Single-Page-Apps, Mobile Apps und Server-Apps.
Sende und prüfe immer state; die OAuth-Spezifikation empfiehlt das zum Schutz vor Cross-Site Request Forgery.
Fordere die engsten Scopes an, die für die Aufgabe reichen; kleinen Anfragen stimmen Menschen eher zu.
Registriere exakte Redirect-URIs. Wildcards und offene Redirects sind ein klassischer Weg, auf dem Tokens gestohlen werden.
Bewahre Client Secrets nur auf dem Server auf. Ein Browser oder eine Mobile App kann kein Geheimnis wahren.
Häufige Fragen
Ist OAuth Authentifizierung oder Autorisierung?
Autorisierung. Ein Access Token sagt, was eine App tun darf, nicht wer der Nutzer ist, und APIs verraten dir das unter Umständen gar nicht. Wenn du die Identität der Person brauchst, verwende OpenID Connect, das ein signiertes ID Token mit Claims wie sub, iss, aud und exp zurückgibt.
Was ist PKCE und brauche ich es?
PKCE (RFC 7636) bindet den Autorisierungscode an die App, die den Flow gestartet hat. Die App sendet zuerst einen Hash eines zufälligen Geheimnisses und später das Geheimnis selbst, daher ist ein gestohlener Code nutzlos. Verwende S256, das Server unterstützen müssen, statt plain.
Was ist der Unterschied zwischen OAuth und SAML?
SAML ist ein älterer, XML-basierter Standard, bei dem ein Identity Provider eine signierte Assertion über den Nutzer an einen Service Provider sendet, meist für Enterprise Single Sign-on im Browser. OAuth stellt Tokens für den API-Zugriff aus und eignet sich gut für Mobile Apps und APIs. OpenID Connect ist in der OAuth-Welt das nähere Gegenstück zur Anmeldung per SAML.
Was sind Scopes?
Scopes sind die Berechtigungen, die eine App anfordert, geschrieben als durch Leerzeichen getrennte Liste von Strings mit Beachtung der Groß- und Kleinschreibung, die der Autorisierungsserver festlegt, zum Beispiel openid email oder repo read:user. Der Zustimmungsbildschirm zeigt sie an, und das Token deckt nur ab, was bestätigt wurde.
Sollte ich den Implicit Flow noch verwenden?
Für neue Projekte nein. Er hat Tokens im URL-Fragment zurückgegeben, wo sie über den Verlauf und Logs durchsickern können. Der Authorization Code Flow mit PKCE bietet Browser-Apps denselben Komfort ohne dieses Risiko.
Die vier Rollen
RFC 6749 nennt vier Beteiligte. Der Resource Owner bist du. Der Client ist die App, die Zugriff anfordert. Der Autorisierungsserver prüft, wer du bist, und stellt Tokens aus. Der Ressourcenserver hostet die API, die diese Tokens akzeptiert. Oft betreibt ein Unternehmen beide Server, aber es sind getrennte Aufgaben.
Warum es den Code-Austausch gibt
Die Weiterleitung zurück zur App läuft über den Browser, und der ist ein undichter Ort für alles Wertvolle. Deshalb trägt die Weiterleitung nur einen Einmalcode, der laut Empfehlung der Spezifikation innerhalb von 10 Minuten abläuft. Das eigentliche Token wird mit einem direkten Aufruf am Token-Endpunkt abgeholt.
PKCE schließt die verbleibende Lücke. Selbst wenn Malware oder ein protokollierender Proxy den Code abfängt, kann er ihn ohne den Verifier, der die App nie verlassen hat, nicht einlösen.
Wo OpenID Connect ins Spiel kommt
OpenID Connect ist eine dünne Schicht über OAuth. Füge openid zu den Scopes hinzu, was die OIDC-Spezifikation vorschreibt, und die Token-Antwort enthält zusätzlich ein ID Token: ein signiertes JWT, das den Nutzer beschreibt. Eine nonce, die in der Anfrage gesendet und im ID Token zurückgegeben wird, schützt vor Replay-Angriffen.
Der Authorization Code Flow mit PKCE
Jeder Schritt und die Parameter, die er mitführt
Schritt
Von, nach
Wichtige Parameter
1. Autorisierungsanfrage
App an Autorisierungsserver (Browser-Weiterleitung)
access_token, token_type, expires_in, optional refresh_token (und id_token bei OIDC)
6. API-Aufruf
App an Ressourcenserver
Authorization: Bearer <access_token>
PKCE im Code
Verifier und S256-Challenge im Browser erzeugen
32 zufällige Bytes als base64url kodiert ergeben einen Verifier mit 43 Zeichen, die kürzeste Länge, die RFC 7636 erlaubt.
Den Code gegen Tokens tauschen
Läuft nach der Weiterleitung. Vergleiche zuerst state und sende dann den gespeicherten Verifier zusammen mit dem Code.
Generator für PKCE und Autorisierungs-URL
Erzeugt mit der Krypto-Funktion deines Browsers einen frischen code_verifier und seine S256-code_challenge und setzt aus deinen Einstellungen eine Autorisierungs-URL zusammen. Es wird nichts gesendet; der Endpunkt unten ist ein Platzhalter, den du ersetzt.
Autorisierungs-Endpunkt
Scopes (durch Leerzeichen getrennt)
Neuer Verifier
code_verifier ({n} Zeichen, bis Schritt 4 geheim halten)