2. JWT Access Token Header and Data Structure (JWT-Zugriffstoken-Header und Datenstruktur)
2.1. Header
JWT-Zugriffstoken müssen (MUST) signiert sein. Obwohl JWT-Zugriffstoken jeden Signaturalgorithmus verwenden können, wird die Verwendung asymmetrischer Kryptographie empfohlen (RECOMMENDED), da sie den Prozess der Beschaffung von Validierungsinformationen für Ressourcenserver vereinfacht (siehe Abschnitt 4). JWT-Zugriffstoken dürfen (MUST NOT) "none" als Signaturalgorithmus verwenden. Siehe Abschnitt 4 für weitere Details.
Autorisierungsserver und Ressourcenserver, die dieser Spezifikation entsprechen, müssen (MUST) RS256 (wie in [RFC7518] definiert) unter ihren unterstützten Signaturalgorithmen einschließen.
Diese Spezifikation registriert den Medientyp (Media Type) "application/at+jwt", der verwendet werden kann, um anzuzeigen, dass der Inhalt ein JWT-Zugriffstoken ist. JWT-Zugriffstoken müssen (MUST) diesen Medientyp im "typ"-Header-Parameter einschließen, um explizit zu deklarieren, dass das JWT ein Zugriffstoken darstellt, das diesem Profil entspricht. Gemäß der Definition von "typ" in Abschnitt 4.1.9 von [RFC7515] wird empfohlen (RECOMMENDED), dass das Präfix "application/" weggelassen wird. Daher sollte (SHOULD) der verwendete "typ"-Wert "at+jwt" sein. Siehe den Abschnitt Sicherheitserwägungen für Details zur Bedeutung der Verhinderung, dass OpenID Connect-ID-Token (wie in Abschnitt 2 von [OpenID.Core] definiert) von Ressourcenservern, die dieses Profil implementieren, als Zugriffstoken akzeptiert werden.
2.2. Data Structure (Datenstruktur)
Die folgenden Claims werden in der Datenstruktur des JWT-Zugriffstokens verwendet.
iss ERFORDERLICH (REQUIRED) - wie in Abschnitt 4.1.1 von [RFC7519] definiert.
exp ERFORDERLICH (REQUIRED) - wie in Abschnitt 4.1.4 von [RFC7519] definiert.
aud ERFORDERLICH (REQUIRED) - wie in Abschnitt 4.1.3 von [RFC7519] definiert. Siehe Abschnitt 3 für Hinweise darauf, wie ein Autorisierungsserver den Wert von "aud" in Abhängigkeit von der Anfrage bestimmen sollte.
sub ERFORDERLICH (REQUIRED) - wie in Abschnitt 4.1.2 von [RFC7519] definiert. Bei Zugriffstoken, die über Gewährungen erhalten werden, bei denen ein Ressourcenbesitzer (Resource Owner) beteiligt ist, wie z.B. die Autorisierungscode-Gewährung (Authorization Code Grant), sollte (SHOULD) der Wert von "sub" dem Subjektidentifikator des Ressourcenbesitzers entsprechen. Bei Zugriffstoken, die über Gewährungen erhalten werden, bei denen kein Ressourcenbesitzer beteiligt ist, wie z.B. die Client-Credentials-Gewährung (Client Credentials Grant), sollte (SHOULD) der Wert von "sub" einem Identifikator entsprechen, den der Autorisierungsserver verwendet, um die Clientanwendung anzuzeigen. Siehe Abschnitt 5 für weitere Details zu diesem Szenario. Siehe auch Abschnitt 6 für eine Diskussion darüber, wie unterschiedliche Entscheidungen bei der Zuweisung von "sub"-Werten die Privatsphäre beeinflussen können.
client_id ERFORDERLICH (REQUIRED) - wie in Abschnitt 4.3 von [RFC8693] definiert.
iat ERFORDERLICH (REQUIRED) - wie in Abschnitt 4.1.6 von [RFC7519] definiert. Dieser Claim identifiziert den Zeitpunkt, zu dem das JWT-Zugriffstoken ausgestellt wurde.
jti ERFORDERLICH (REQUIRED) - wie in Abschnitt 4.1.7 von [RFC7519] definiert.
2.2.1. Authentication Information Claims (Authentifizierungsinformations-Claims)
Die in diesem Abschnitt aufgeführten Claims können (MAY) im Kontext von Autorisierungsgewährungen ausgestellt werden, an denen der Ressourcenbesitzer beteiligt ist, und spiegeln die Arten und Stärke der Authentifizierung im Zugriffstoken wider, die der Authentifizierungsserver erzwungen hat, bevor er die Autorisierungsantwort an den Client zurückgab. Ihre Werte sind fest und bleiben für alle Zugriffstoken gleich, die von einer bestimmten Autorisierungsantwort abgeleitet sind, unabhängig davon, ob das Zugriffstoken direkt in der Antwort erhalten wurde (z.B. über den Implicit Flow) oder nach einem oder mehreren Token-Austauschen (z.B. Erhalt eines neuen Zugriffstokens mit einem Aktualisierungstoken oder Austausch eines Zugriffstokens gegen ein anderes über [RFC8693]-Verfahren).
auth_time OPTIONAL - wie in Abschnitt 2 von [OpenID.Core] definiert.
acr OPTIONAL - wie in Abschnitt 2 von [OpenID.Core] definiert.
amr OPTIONAL - wie in Abschnitt 2 von [OpenID.Core] definiert.
2.2.2. Identity Claims (Identitäts-Claims)
Im Kontext von Autorisierungsgewährungen, an denen der Ressourcenbesitzer beteiligt ist, fügen kommerzielle Autorisierungsserver häufig Ressourcenbesitzer-Attribute direkt in Zugriffstoken ein, damit Ressourcenserver sie direkt für Autorisierungs- oder andere Zwecke verwenden können, ohne weitere Roundtrips zu Introspection-([RFC7662]) oder UserInfo-([OpenID.Core])-Endpunkten. Dies ist besonders häufig in Szenarien, in denen Client und Ressourcenserver zur selben Entität gehören und Teil derselben Lösung sind, wie es bei First-Party-Clients der Fall ist, die ihre eigene Backend-API aufrufen.
Dieses Profil führt keinen Mechanismus ein, mit dem ein Client direkt das Vorhandensein bestimmter Claims in JWT-Zugriffstoken anfordern kann, da der Autorisierungsserver bestimmen kann, welche zusätzlichen Claims ein bestimmter Ressourcenserver benötigt, indem er die client_id des Clients und die in der Anfrage enthaltenen Parameter "scope" und "resource" berücksichtigt.
Jedes zusätzliche Identitätsattribut, dessen Semantik durch einen Eintrag in der in [RFC7519] eingeführten IANA-Registry "JSON Web Token (JWT)" gut beschrieben wird, sollte (SHOULD) mit dem entsprechenden Claim-Namen codiert werden, wenn dieses Attribut im JWT-Zugriffstoken enthalten sein soll. Beachten Sie, dass die JWT-IANA-Registry die in Abschnitt 5.1 von [OpenID.Core] gefundenen Claims enthält.
Autorisierungsserver können (MAY) beliebige Attribute zurückgeben, die in keiner bestehenden Spezifikation definiert sind, solange die entsprechenden Claim-Namen kollisionsresistent sind oder die Zugriffstoken nur innerhalb eines privaten Subsystems verwendet werden sollen. Bitte beachten Sie die Abschnitte 4.2 und 4.3 von [RFC7519] für Details.
Autorisierungsserver, die Ressourcenbesitzer-Attribute in JWT-Zugriffstoken einschließen, müssen Vorsicht walten lassen und überprüfen, dass alle Datenschutzanforderungen erfüllt sind, wie in Abschnitt 6 diskutiert.
2.2.3. Authorization Claims (Autorisierungs-Claims)
Wenn eine Autorisierungsanfrage einen Scope-Parameter enthält, sollte (SHOULD) das entsprechend ausgestellte JWT-Zugriffstoken einen "scope"-Claim wie in Abschnitt 4.2 von [RFC8693] definiert enthalten.
Alle einzelnen Scope-Strings im "scope"-Claim müssen (MUST) eine Bedeutung für die im "aud"-Claim angegebenen Ressourcen haben. Siehe Abschnitt 5 für weitere Überlegungen zur Beziehung zwischen Scope-Strings und den durch den "aud"-Claim angegebenen Ressourcen.
2.2.3.1. Claims for Authorization Outside of Delegation Scenarios (Claims für Autorisierung außerhalb von Delegierungsszenarien)
Viele Autorisierungsserver betten Autorisierungsattribute ein, die über die in [RFC7519] beschriebenen Delegierungsszenarien hinausgehen, in die von ihnen ausgestellten Zugriffstoken. Typische Beispiele umfassen Mitgliedschaften des Ressourcenbesitzers in Rollen (Role) und Gruppen (Group), die für die aufgerufene Ressource relevant sind, dem Ressourcenbesitzer für die Zielressource zugewiesene Berechtigungen (Entitlement), die der Autorisierungsserver kennt, usw.
Ein Autorisierungsserver, der solche Attribute in ein JWT-Zugriffstoken aufnehmen möchte, sollte (SHOULD) die Attribute "groups", "roles" und "entitlements" des "User"-Ressourcenschemas, das in Abschnitt 4.1.2 von [RFC7643] definiert ist, als Claim-Typen verwenden.
Autorisierungsserver sollten (SHOULD) die entsprechenden Claim-Werte gemäß den in [RFC7643] definierten Richtlinien codieren. Insbesondere ist ein nicht-normatives Beispiel eines "groups"-Attributs in Abschnitt 8.2 von [RFC7643] zu finden. Für "roles" und "entitlements" wird kein spezifisches Vokabular bereitgestellt.
Abschnitt 7.2.1 dieses Dokuments enthält Einträge zur Registrierung der Attribute "groups", "roles" und "entitlements" aus [RFC7643] als Claim-Typen zur Verwendung in diesem Profil.