4. Validating JWT Access Tokens (Validierung von JWT-Zugriffstoken)

Um das Abrufen von Validierungsdaten zu erleichtern, wird hier empfohlen (RECOMMENDED), dass Autorisierungsserver JWT-Zugriffstoken mit einem asymmetrischen Algorithmus signieren.

Autorisierungsserver sollten (SHOULD) OAuth 2.0 Authorization Server Metadata [RFC8414] verwenden, um Ressourcenservern ihre Signaturschlüssel über "jwks_uri" und den zu erwartenden "iss"-Claim-Wert über den "issuer"-Metadatenwert bekannt zu geben. Alternativ können (MAY) Autorisierungsserver, die OpenID Connect implementieren, das OpenID Connect Discovery-Dokument [OpenID.Discovery] für denselben Zweck verwenden. Wenn ein Autorisierungsserver sowohl OAuth 2.0 Authorization Server Metadata als auch OpenID Connect Discovery unterstützt, müssen (MUST) die bereitgestellten Werte über die beiden Veröffentlichungsmethoden hinweg konsistent sein.

Ein Autorisierungsserver kann (MAY) sich dafür entscheiden, unterschiedliche Schlüssel zum Signieren von OpenID Connect-ID-Token und JWT-Zugriffstoken zu verwenden. Diese Spezifikation bietet keinen Mechanismus zur Identifizierung eines bestimmten Schlüssels als den zum Signieren von JWT-Zugriffstoken verwendeten. Ein Autorisierungsserver kann JWT-Zugriffstoken mit einem beliebigen der über Autorisierungsserver-(AS-)Metadaten oder OpenID Connect Discovery angekündigten Schlüssel signieren. Siehe Abschnitt 5 für weitere Hinweise zu Sicherheitsimplikationen.

Ressourcenserver, die ein JWT-Zugriffstoken erhalten, müssen (MUST) es auf folgende Weise validieren.

Der Ressourcenserver muss (MUST) überprüfen, dass der "typ"-Header-Wert "at+jwt" oder "application/at+jwt" ist, und Token mit einem anderen Wert ablehnen.
Wenn das JWT-Zugriffstoken verschlüsselt ist, entschlüsseln Sie es mit den Schlüsseln und Algorithmen, die der Ressourcenserver bei der Registrierung angegeben hat. Wenn die Verschlüsselung bei der Registrierung mit dem Autorisierungsserver ausgehandelt wurde und das eingehende JWT-Zugriffstoken nicht verschlüsselt ist, sollte (SHOULD) der Ressourcenserver es ablehnen.
Der Ausstelleridentifikator für den Autorisierungsserver (der typischerweise während der Discovery erhalten wird) muss (MUST) exakt mit dem Wert des "iss"-Claims übereinstimmen.
Der Ressourcenserver muss (MUST) validieren, dass der "aud"-Claim einen Ressourcenindikatorwert enthält, der einem Identifikator entspricht, den der Ressourcenserver für sich selbst erwartet. Das JWT-Zugriffstoken muss (MUST) abgelehnt werden, wenn "aud" keinen Ressourcenindikator des aktuellen Ressourcenservers als gültiges Publikum enthält.
Der Ressourcenserver muss (MUST) die Signatur aller eingehenden JWT-Zugriffstoken gemäß [RFC7515] unter Verwendung des im JWT-"alg"-Header-Parameter angegebenen Algorithmus validieren. Der Ressourcenserver muss (MUST) jedes JWT ablehnen, bei dem der Wert von "alg" "none" ist. Der Ressourcenserver muss (MUST) die vom Autorisierungsserver bereitgestellten Schlüssel verwenden.
Die aktuelle Zeit muss (MUST) vor der durch den "exp"-Claim dargestellten Zeit liegen. Implementierer können (MAY) eine kleine Toleranz vorsehen, in der Regel nicht mehr als einige Minuten, um Uhrenabweichungen zu berücksichtigen.

Der Ressourcenserver muss (MUST) Fehler wie in Abschnitt 3.1 von [RFC6750] beschrieben behandeln. Insbesondere muss (MUST) die Antwort des Autorisierungsservers bei jedem Fehler in den oben aufgeführten Validierungsprüfungen den Fehlercode "invalid_token" enthalten. Bitte beachten Sie, dass diese Anforderung JWT-Zugriffstoken nicht daran hindert, andere Authentifizierungsschemata als "Bearer" zu verwenden.

Wenn das JWT-Zugriffstoken Autorisierungs-Claims wie in Abschnitt 2.2.3 beschrieben enthält, sollte (SHOULD) der Ressourcenserver diese in Kombination mit anderen verfügbaren Kontextinformationen verwenden, um zu bestimmen, ob der aktuelle Aufruf autorisiert oder abgelehnt werden soll. Details darüber, wie ein Ressourcenserver diese Prüfungen durchführt, liegen außerhalb des Geltungsbereichs dieser Profilspezifikation.