Vier Rollen und drei verschiedene Token
Ein Beispiel: Eine Dokumenten-App soll freigegebene Dateien aus einer API anzeigen. Der Benutzer ist der Ressourceninhaber. Die App ist der Client. Der Autorisierungsserver verarbeitet die Freigabe und gibt Token aus. Die Dokumenten-API ist der Ressourcenserver, der Zugriffe anhand seines Vertrags prüft. Diese Rollen können organisatorisch zusammengehören, bleiben technisch aber verschiedene Empfänger. Die Grundlage beschreibt RFC 6749, Abschnitt 1.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Gegenstand | Aufgabe und Empfänger | Häufige Fehlannahme |
|---|---|---|
| Access-Token | Zugriffsnachweis für die dafür vorgesehene API | Jedes gültige Token dürfe jede API aufrufen |
| ID-Token | Aussage des OpenID Providers über die Anmeldung für den Client | Es sei automatisch das Zugriffstoken für eine Fach-API |
| Refresh-Token | Beim Autorisierungsserver ein neues Access-Token erhalten | Es müsse bei jedem Ressourcenaufruf mitgeschickt werden |
OpenID Connect verlangt für das ID-Token unter anderem die passende Aussteller- und Empfängerzuordnung. Sein aud bezieht sich auf den Client. Die Fach-API braucht dagegen ein für sie ausgestelltes und nach ihrem Profil validiertes Access-Token. Siehe OpenID Connect Core, Abschnitte 2 und 3.1.3.7.
Der Clienttyp bestimmt den Umgang mit Geheimnissen
Ein vertraulicher Client kann Zugangsdaten in einer kontrollierten serverseitigen Umgebung schützen. Ein öffentlicher Client – etwa ausgeliefertes Browser-JavaScript – kann ein eingebautes gemeinsames Geheimnis nicht geheim halten. Ein client_id ist ohnehin eine Kennung und kein Geheimnis.
PKCE ersetzt diese Unterscheidung nicht. Es bindet die Einlösung eines Autorisierungscodes an einen Wert, den der betreffende Client für diesen Ablauf erzeugt hat. Es ist weder ein Benutzerpasswort noch allein eine Authentifizierung des Clients. Bei einem Dienst ohne interaktive Benutzerfreigabe kommt ein anderer Ablauf wie Client Credentials infrage. Treffen Sie diese Wahl anhand der Authentifizierungsaufgabe.
Authorization Code mit PKCE nachvollziehen
Der folgende Ablauf ist ein synthetisches Anschauungsbeispiel. Endpunkte und Details kommen in einer echten Integration aus der vertrauenswürdigen Konfiguration und dem verwendeten SDK.
- Die App beginnt einen neuen Anmelde- oder Freigabevorgang und erzeugt einen zufälligen, nur für diesen Vorgang verwendeten
code_verifier. Daraus berechnet sie die PKCE-Challenge mitS256. - Sie leitet den Browser zum bekannten Autorisierungsendpunkt. Mitgesendet werden unter anderem Clientkennung, registrierte Rücksprungadresse, gewünschte Rechte und Challenge. OIDC verwendet zusätzlich seinen Anmeldekontext.
- Der Autorisierungsserver verarbeitet Anmeldung und erforderliche Freigabe. Er sendet einen kurzlebigen Code über den Browser an die festgelegte Rücksprungadresse.
- Der Client ordnet diese Antwort dem begonnenen Vorgang zu und löst den Code am Tokenendpunkt ein. Dabei legt er den
code_verifierund, sofern vorgesehen, seine Clientauthentifizierung vor. - Nach erfolgreicher Prüfung gibt der Autorisierungsserver die für diesen Vorgang vorgesehenen Token zurück. Der Client validiert die für ihn bestimmten Antworten und verwendet das Access-Token ausschließlich für die passende API.
RFC 7636, Abschnitt 4 beschreibt die PKCE-Bindung. Die aktuelle Sicherheitsgrundlage RFC 9700, Abschnitt 2.1.1 fordert PKCE für öffentliche Clients und empfiehlt es für vertrauliche Clients. S256 vermeidet, dass der Verifier bereits in der Autorisierungsanfrage offenliegt.
Synthetischer Clientfall · kein ausgeführter Login
Vom Anmeldevorgang zur Berechtigungsprüfung der API
Beispiel: Eine serverseitige Dokumenten-App ist der vertrauliche Client. Der Benutzer ist der Ressourceninhaber und bedient sie im Browser. Das App-Backend nutzt OIDC und Authorization Code mit PKCE, löst den Code selbst ein und ruft die Dokumenten-API auf. Der Autorisierungsserver ist zugleich der OpenID Provider; die Dokumenten-API ist der Ressourcenserver.
- App-Backend: neuen Vorgang beginnen
Der Client erzeugt einen zufälligen
code_verifiernur für diesen Vorgang und berechnet daraus die PKCE-Challenge mitS256. - App-Backend → Browser → Autorisierungsserver
Der Browser wird zum bekannten Autorisierungsendpunkt geleitet: mit Clientkennung, registrierter Rücksprungadresse, gewünschten Rechten, Challenge und OIDC-Anmeldekontext.
- Benutzer ↔ Autorisierungsserver
Der Server verarbeitet die Anmeldung des Benutzers und die erforderliche Freigabe.
- Autorisierungsserver → Browser → App-Backend
Ein kurzlebiger Code kommt an der festgelegten Rücksprungadresse an. Der Client prüft die Zuordnung zum begonnenen Vorgang.
- App-Backend ↔ Tokenendpunkt
Der Client löst den Code mit dem
code_verifierund seiner vorgesehenen Clientauthentifizierung ein. Erst nach erfolgreicher Prüfung gibt der Autorisierungsserver die vorgesehenen Token zurück.- ID-Token → Client
- Beschreibt die Anmeldung. Der Client validiert es einschließlich Aussteller und Empfänger; es ist kein Zugriffstoken für die Dokumenten-API.
- Access-Token → passende API
- Ist für den vereinbarten API-Zugriff bestimmt. Der Client verwendet es nur gegenüber der vorgesehenen API.
- App-Backend → Dokumenten-API
Die API prüft das Access-Token für ihren Empfängerkontext, seine Gültigkeit und die Rechte. Zusätzlich entscheidet sie, welche Objekte, Felder und Funktionen dieser Zugriff nutzen darf. Der Scope
documents:readallein erlaubt nicht jedes Dokument.
Bindung und Rechte bleiben verschiedene Prüfungen: PKCE bindet die Codeeinlösung an den Verifier; es authentifiziert den Client nicht allein. state und bei OIDC nonce haben eigene Aufgaben und Bedingungen. Die vollständige Integration muss Transaktionsbindung, CSRF-Schutz und die korrekte Ausstellerzuordnung leisten. Ein erfolgreicher Login ersetzt keine API-Berechtigungsprüfung.
Rücksprungadresse und Vorgang gehören zusammen
Registrieren Sie konkrete Rücksprungadressen und verwenden Sie die Prüfung des Anbieters gemäß aktuellem Protokollprofil. Breite Muster und offene Weiterleitungen erhöhen das Risiko, dass eine Antwort beim falschen Empfänger endet. Die eng gefasste Ausnahme für Loopback-Ports nativer Apps ist keine Freigabe für beliebige Web-Redirects.
Der Client muss zudem erkennen, ob die Antwort zum tatsächlich begonnenen Vorgang gehört. PKCE, state und bei OIDC nonce haben dabei unterschiedliche Aufgaben und Bedingungen. Entfernen Sie diese Schutzmechanismen nicht eigenständig, weil eine Anleitung „PKCE verhindert CSRF“ verkürzt. Die vollständige Bibliotheks- und Anbieterintegration muss Transaktionsbindung, CSRF-Schutz und bei mehreren Ausstellern die korrekte Ausstellerzuordnung leisten. RFC 9700, Abschnitt 2.1 legt diese Anforderungen zusammen dar.
Für neue Integrationen ist ein Ablauf, bei dem der Client das Hauptpasswort des Benutzers entgegennimmt, keine geeignete Abkürzung. Der Resource Owner Password Credentials Grant darf nach RFC 9700 nicht mehr eingesetzt werden. Access-Token direkt in Autorisierungsantworten gehören ebenfalls nicht zum hier empfohlenen Codeablauf.
Was die API nach der Anmeldung noch prüfen muss
Die API prüft das Access-Token für ihren eigenen Empfängerkontext, dessen Gültigkeit und die zugelassenen Rechte. Das kann je nach Vertrag eine lokale JWT-Validierung oder eine serverseitige Tokenauskunft erfordern. „Der Login war erfolgreich“ ersetzt diese Prüfung nicht.
Ein Scope wie documents:read benennt einen vereinbarten Rechtebereich. Er beantwortet noch nicht, welches Dokument einem Benutzer oder Mandanten gehört. Die API muss daher zusätzlich Objekt-, Feld- und Funktionsrechte durchsetzen. Für strukturierte Access-Token führt der Weg zur JWT-Validierung, für die Fachregel zu Objektberechtigungen.
Speichern Sie Token nicht in URLs oder vollständigen Logs. Transportieren Sie sie ausschließlich zu den vorgesehenen Empfängern. Eine Signatur macht Claims nicht automatisch vertraulich und ein gültiges Bearer-Token kann nach Diebstahl bis zu seiner wirksamen Begrenzung missbraucht werden.
Refresh, Logout und Widerruf getrennt planen
Ein Refresh-Token kann den Zugriff über die Laufzeit eines einzelnen Access-Tokens hinaus ermöglichen. Für öffentliche Clients verlangt RFC 9700 eine Senderbindung oder Refresh-Token-Rotation. Bei Rotation müssen Wiederverwendung, parallele Erneuerungen und abgebrochene Antworten im konkreten Anbieter- und Clientverhalten berücksichtigt werden. Eine selbst ergänzte Endlosschleife beim Refresh ist keine Fehlerbehandlung.
Logout, Sitzungssperrung und Tokenwiderruf sind verschiedene Vorgänge. Der Widerrufsstandard RFC 7009 beschreibt einen eigenen Endpunkt und die mögliche Wirkung auf zugehörige Token. Ob ein bereits ausgegebenes Access-Token sofort überall unwirksam wird, hängt von Tokenart, Prüfung und Verteilung des Sperrzustands ab. Definieren und prüfen Sie diese Zusage ausdrücklich.
Den eigenen Ablauf begrenzt verifizieren
Nutzen Sie Testbenutzer und eine eigene Testregistrierung. Prüfen Sie den regulären Zugang sowie eine abweichende Rücksprungadresse, einen fehlenden oder unpassenden Verifier, eine nicht zugehörige Rückkehr und ein Access-Token für eine andere API. Erwartungen ergeben sich aus Ihrem Profil; verwenden Sie keine fremden Konten und keine realen Produktionswerte in Diagnosewerkzeugen.
Prüfen Sie anschließend Ablauf, Sitzungssperrung und Widerruf aus Benutzersicht. Belegen Sie, welcher Zugang wann nicht mehr funktioniert. Für die Einführung halten Sie eine vorherige funktionierende Clientkonfiguration bereit. Wird ein Geheimnis kompromittiert, erfolgt die Rücknahme mit neuen vertrauenswürdigen Zugangsdaten, nicht durch Reaktivierung des alten Wertes.
Der API Security Check führt keine Anmeldung, Tokenprüfung oder Rollenprüfung durch. Ein passender Nachweis entsteht hier aus einer korrekt konfigurierten Protokollimplementierung und eigenen Integrationstests. Quellenstand: 27. September 2026; OIDC Core 1.0 einschließlich Errata Set 2 und OAuth-Sicherheits-BCP RFC 9700.
Quellen und Stand
Quellenstand: 27. September 2026. Die Links stehen zusätzlich bei den jeweils begründeten Aussagen.