1. Introduction (Einführung)
Die ursprüngliche OAuth 2.0 Authorization Framework-Spezifikation [RFC6749] schreibt kein spezifisches Format für Zugriffstoken (Access Token) vor. Obwohl dies für viele wichtige Szenarien nach wie vor völlig angemessen ist, hat die Marktnutzung gezeigt, dass viele kommerzielle OAuth 2.0-Implementierungen sich dafür entschieden haben, Zugriffstoken in einem Format auszustellen, das von Ressourcenservern (Resource Server) direkt geparst und validiert werden kann, ohne weitere Beteiligung des Autorisierungsservers (Authorization Server). Dieser Ansatz ist besonders häufig in Topologien, in denen der Autorisierungsserver und der Ressourcenserver nicht am selben Ort sind, nicht von derselben Entität betrieben werden oder anderweitig durch eine Grenze getrennt sind. Zum Zeitpunkt der Erstellung nutzen viele kommerzielle Implementierungen das JSON Web Token (JWT)-Format [RFC7519].
Viele herstellerspezifische JWT-Zugriffstoken teilen dasselbe funktionale Layout und verwenden JWT-Claims (Claim), um die Informationen zu übermitteln, die zur Unterstützung eines gemeinsamen Satzes von Anwendungsfällen erforderlich sind: Token-Validierung, Übertragung von Autorisierungsinformationen in Form von Bereichen (Scope) und Berechtigungen (Entitlement), Übertragung von Identitätsinformationen über das Subjekt (Subject) usw. Die Unterschiede beschränken sich hauptsächlich auf die Claim-Namen und die Syntax, die zur Darstellung derselben Entitäten verwendet werden, was darauf hindeutet, dass Interoperabilität leicht durch Standardisierung eines gemeinsamen Satzes von Claims und Validierungsregeln erreicht werden könnte.
Die Annahme, dass Zugriffstoken mit bestimmten Informationen verknüpft sind, erscheint nicht nur in kommerziellen Implementierungen. Verschiedene Spezifikationen der OAuth 2.0-Familie (wie Resource Indicators [RFC8707], OAuth 2.0 Bearer Token Usage [RFC6750] und andere) setzen das Vorhandensein von Bereichsmechanismen wie einer Zielgruppe (Audience) in Zugriffstoken voraus. Die mit Introspection (Introspection) verbundene Spezifikationsfamilie deutet auch indirekt auf einen grundlegenden Satz von Informationen hin, die Zugriffstoken tragen oder zumindest damit verknüpft sein sollten.
Diese Spezifikation zielt darauf ab, ein standardisiertes und interoperables Profil (Profile) als Alternative zu zukünftigen proprietären JWT-Zugriffstokenlayouts bereitzustellen. Neben der Definition eines gemeinsamen Satzes obligatorischer und optionaler Claims bietet das Profil klare Hinweise darauf, wie Autorisierungsanforderungsparameter den Inhalt ausgestellter JWT-Zugriffstoken bestimmen, wie ein Autorisierungsserver relevante Metadaten zu den von ihm ausgestellten JWT-Zugriffstoken veröffentlichen kann und wie ein Ressourcenserver eingehende JWT-Zugriffstoken validieren sollte.
Schließlich bietet diese Spezifikation Sicherheits- und Datenschutzüberlegungen, die darauf abzielen, häufige Fehler und Antimuster zu verhindern, die bei naiver Verwendung des JWT-Formats zur Darstellung von Zugriffstoken auftreten können.
Bitte beachten Sie: Obwohl sowohl dieses Dokument als auch [RFC7523] JSON Web Tokens im Kontext des OAuth2-Frameworks verwenden, unterscheiden sich die beiden Spezifikationen sowohl in ihrer Absicht als auch in ihren Mechanismen. Während [RFC7523] definiert, wie ein JWT-Bearer-Token (JWT Bearer Token) verwendet werden kann, um ein Zugriffstoken anzufordern, beschreibt dieses Dokument, wie Zugriffstoken im JWT-Format codiert werden.
1.1. Requirements Notation and Conventions (Anforderungsnotation und Konventionen)
Die Schlüsselwörter "MUST" (muss), "MUST NOT" (darf nicht), "REQUIRED" (erforderlich), "SHALL" (muss), "SHALL NOT" (darf nicht), "SHOULD" (sollte), "SHOULD NOT" (sollte nicht), "RECOMMENDED" (empfohlen), "NOT RECOMMENDED" (nicht empfohlen), "MAY" (kann) und "OPTIONAL" (optional) in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.
1.2. Terminology (Terminologie)
JWT-Zugriffstoken (JWT access token): Ein OAuth 2.0-Zugriffstoken, das im JWT-Format codiert ist und den in dieser Spezifikation beschriebenen Anforderungen entspricht.
Diese Spezifikation verwendet die Begriffe "access token" (Zugriffstoken), "refresh token" (Aktualisierungstoken), "authorization server" (Autorisierungsserver), "resource server" (Ressourcenserver), "authorization endpoint" (Autorisierungsendpunkt), "authorization request" (Autorisierungsanfrage), "authorization response" (Autorisierungsantwort), "token endpoint" (Token-Endpunkt), "grant type" (Gewährungstyp), "access token request" (Zugriffstokenanfrage), "access token response" (Zugriffstokenantwort) und "client" (Client), die im OAuth 2.0 Authorization Framework [RFC6749] definiert sind.