5. Security Considerations (Sicherheitserwägungen)
Das hier beschriebene JWT-Zugriffstokendatenlayout ist dem des id_token, wie in [OpenID.Core] definiert, sehr ähnlich. Die in diesem Profil erforderliche explizite Typisierung, in Übereinstimmung mit den Empfehlungen in [RFC8725], hilft dem Ressourcenserver, zwischen JWT-Zugriffstoken und OpenID Connect-ID-Token zu unterscheiden.
Autorisierungsserver sollten Szenarien verhindern, in denen Clients den Wert des "sub"-Claims auf eine Weise beeinflussen können, die Ressourcenserver verwirren könnte. Wenn der Autorisierungsserver beispielsweise beschließt, die client_id als "sub"-Wert für Zugriffstoken zu verwenden, die mit der Client-Credentials-Gewährung ausgestellt werden, sollte der Autorisierungsserver verhindern, dass Clients einen beliebigen client_id-Wert registrieren, da dies böswilligen Clients ermöglichen würde, das Sub eines hochprivilegierten Ressourcenbesitzers auszuwählen und jede Autorisierungslogik auf dem Ressourcenserver zu verwirren, die sich auf den "sub"-Wert stützt. Für weitere Details siehe bitte Abschnitt 4.14 von [OAuth2.Security.BestPractices].
Um Cross-JWT-Verwirrung (Cross-JWT Confusion) zu verhindern, müssen (MUST) Autorisierungsserver einen eindeutigen Identifikator als "aud"-Claim-Wert verwenden, um Zugriffstoken, die vom selben Aussteller für verschiedene Ressourcen ausgestellt wurden, eindeutig zu identifizieren. Für weitere Details zur Cross-JWT-Verwirrung siehe bitte Abschnitt 2.8 von [RFC8725].
Autorisierungsserver sollten besondere Vorsicht walten lassen, wenn sie Anfragen bearbeiten, die zu mehrdeutigen Autorisierungsgewährungen führen könnten. Wenn eine Anfrage beispielsweise mehrere Ressourcenindikatoren enthält, sollte der Autorisierungsserver sicherstellen, dass jeder im resultierenden JWT-Zugriffstoken enthaltene Scope-String, falls vorhanden, eindeutig mit einer bestimmten Ressource unter den im "aud"-Claim aufgeführten korreliert werden kann. Die Details zur Erkennung und Abmilderung dieser und anderer mehrdeutiger Situationen hängen stark vom Szenario ab und liegen daher außerhalb des Geltungsbereichs dieses Profils.
Autorisierungsserver können sich nicht darauf verlassen, unterschiedliche Schlüssel zum Signieren von OpenID Connect-ID-Token und JWT-Token zu verwenden, um sich gegen die Folgen des Durchsickerns bestimmter Schlüssel zu schützen. Da Ressourcenserver keine Möglichkeit haben zu wissen, welcher Schlüssel speziell zur Validierung von JWT-Zugriffstoken verwendet werden sollte, müssen sie Signaturen akzeptieren, die mit einem der in AS-Metadaten oder OpenID Connect Discovery veröffentlichten Schlüssel durchgeführt wurden; folglich muss ein Angreifer nur einen beliebigen der veröffentlichten Schlüssel kompromittieren, um JWTs generieren und signieren zu können, die vom Ressourcenserver als gültig akzeptiert werden.