OpenID Connect · OAuth 2.0
Das Protokoll hat nie aufgehört, sich zu entwickeln. Hier steht, was geschah, warum und was ID-Kit schon testen kann.
Erste Version: Jeder Aufruf wird signiert. Aufwendig zu implementieren, daher das, was folgte.
Das Protokoll wird zum RFC.
Das aktuelle Rahmenwerk: Code, Implicit, Password, Client Credentials, dazu Bearer-Token.
Ein Token vor seinem Ablauf ungültig machen.
Identität auf OAuth: ID-Token, Userinfo, Standard-Scopes, Discovery.
Das signierte Token-Format und die Authentifizierung per Assertion (SAML oder JWT) statt per Geheimnis. ID-Kit: JWT und JWT-Assertion auf Seite des Test-Providers (nicht die SAML-Assertion).
Ein Client kann sich über eine API selbst registrieren.
Bindet den Code an den, der ihn angefordert hat. Für Mobile geboren, heute überall verlangt.
Den Provider fragen, ob ein Token aktiv ist.
Systembrowser statt eingebetteter Ansicht. Schluss mit in die Anwendung getippten Passwörtern.
OAuth-Discovery (das Äquivalent zu .well-known/openid-configuration).
Sich von einem Gerät ohne Tastatur über einen anderen Bildschirm anmelden.
Ein Token gegen ein anderes tauschen (Delegation, Audience-Wechsel).
Client-Authentifizierung per Zertifikat und zertifikatsgebundene Token.
Die Autorisierungsanfrage ist ein signiertes JWT.
Die Autorisierungsanfrage von Server zu Server pushen.
Ein Standardformat für JWT-Access-Token (typ at+jwt).
CIBA: Authentifizierung auf einem anderen Gerät. JARM: Autorisierungsantwort als signiertes JWT.
Schützt vor dem „Mix-up“-Angriff.
Detaillierte Autorisierungen („50 € an X zahlen“) statt einfacher Scopes.
Ein an einen Client-Schlüssel gebundenes Token; eine API kann stärkere Authentifizierung verlangen.
Core, Discovery, Dynamic Registration und die Abmelde-Spezifikationen als ISO/IEC 26131 bis 26139 veröffentlicht.
Das „BCP“, das Implicit und Password begräbt und PKCE sowie den exakten redirect_uri-Vergleich vorschreibt.
Eine API gibt bekannt, welchen Autorisierungsserver sie akzeptiert.
Finanz-Sicherheitsprofil (PAR, PKCE, gebundene Token) und überprüfbare Identitäten: Ausstellung und Vorlage von Nachweisen in einer digitalen Wallet.
Selektive Offenlegung in einem JWT; zwischen Providern geteilte Sicherheitssignale (kontinuierlicher Widerruf).
Vertrauensketten zwischen Providern und Clients im großen Maßstab (Bildung, öffentliche Verwaltungen).
Konsolidiert OAuth 2.0 und Best Practices: Implicit und Password entfernt, PKCE verpflichtend. Stand 31 Oktober 2026 noch kein RFC.
Identity Chaining (Identität über Domains hinweg weitergeben), rfc7523bis (Überarbeitung der JWT-Authentifizierung), Status List, Überarbeitung der JWT-Best-Practices.
Dutzende Entwürfe zur Autorisierung von Agenten: Transaction Tokens, Delegation, Identity Assertion Authorization Grant. Nichts hat sich stabilisiert: beobachten, nicht implementieren.
Quellen: oauth.net/specs, openid.net/developers/specs. Daten geprüft am 1er November 2026; manche Einträge haben nur das Jahr. Siehe auch die Abläufe in Diagrammen und Welchen Ablauf soll ich wählen?