4. Validating JWT Access Tokens (Validation des jetons d'accès JWT)

Dans le but de faciliter la récupération des données de validation, il est recommandé (RECOMMENDED) ici que les serveurs d'autorisation signent les jetons d'accès JWT avec un algorithme asymétrique.

Les serveurs d'autorisation devraient (SHOULD) utiliser les métadonnées du serveur d'autorisation OAuth 2.0 (OAuth 2.0 Authorization Server Metadata) [RFC8414] pour annoncer aux serveurs de ressources leurs clés de signature via "jwks_uri" et la valeur de revendication "iss" à attendre via la valeur de métadonnées "issuer". Alternativement, les serveurs d'autorisation implémentant OpenID Connect peuvent (MAY) utiliser le document de découverte OpenID Connect (Discovery) [OpenID.Discovery] dans le même but. Si un serveur d'autorisation prend en charge à la fois les métadonnées du serveur d'autorisation OAuth 2.0 et la découverte OpenID Connect, les valeurs fournies doivent (MUST) être cohérentes entre les deux méthodes de publication.

Un serveur d'autorisation peut (MAY) choisir d'utiliser différentes clés pour signer les jetons d'identité OpenID Connect et les jetons d'accès JWT. Cette spécification ne fournit pas de mécanisme pour identifier une clé spécifique comme celle utilisée pour signer les jetons d'accès JWT. Un serveur d'autorisation peut signer des jetons d'accès JWT avec n'importe laquelle des clés annoncées via les métadonnées du serveur d'autorisation (AS) ou la découverte OpenID Connect. Voir la Section 5 pour des conseils supplémentaires sur les implications en matière de sécurité.

Les serveurs de ressources recevant un jeton d'accès JWT doivent (MUST) le valider de la manière suivante.

Le serveur de ressources doit (MUST) vérifier que la valeur de l'en-tête "typ" est "at+jwt" ou "application/at+jwt" et rejeter les jetons portant toute autre valeur.
Si le jeton d'accès JWT est chiffré, le déchiffrer en utilisant les clés et les algorithmes que le serveur de ressources a spécifiés lors de l'enregistrement. Si le chiffrement a été négocié avec le serveur d'autorisation au moment de l'enregistrement et que le jeton d'accès JWT entrant n'est pas chiffré, le serveur de ressources devrait (SHOULD) le rejeter.
L'identifiant de l'émetteur pour le serveur d'autorisation (qui est généralement obtenu lors de la découverte) doit (MUST) correspondre exactement à la valeur de la revendication "iss".
Le serveur de ressources doit (MUST) valider que la revendication "aud" contient une valeur d'indicateur de ressource correspondant à un identifiant que le serveur de ressources attend pour lui-même. Le jeton d'accès JWT doit (MUST) être rejeté si "aud" ne contient pas d'indicateur de ressource du serveur de ressources actuel en tant que public valide.
Le serveur de ressources doit (MUST) valider la signature de tous les jetons d'accès JWT entrants conformément à [RFC7515] en utilisant l'algorithme spécifié dans le paramètre d'en-tête "alg" du JWT. Le serveur de ressources doit (MUST) rejeter tout JWT dans lequel la valeur de "alg" est "none". Le serveur de ressources doit (MUST) utiliser les clés fournies par le serveur d'autorisation.
L'heure actuelle doit (MUST) être antérieure à l'heure représentée par la revendication "exp". Les implémenteurs peuvent (MAY) prévoir une petite marge, généralement pas plus de quelques minutes, pour tenir compte du décalage d'horloge.

Le serveur de ressources doit (MUST) gérer les erreurs comme décrit dans la Section 3.1 de [RFC6750]. En particulier, en cas d'échec de l'une des vérifications de validation énumérées ci-dessus, la réponse du serveur d'autorisation doit (MUST) inclure le code d'erreur "invalid_token". Veuillez noter que cette exigence n'empêche pas les jetons d'accès JWT d'utiliser des schémas d'authentification autres que "Bearer".

Si le jeton d'accès JWT inclut des revendications d'autorisation comme décrit dans la Section 2.2.3, le serveur de ressources devrait (SHOULD) les utiliser en combinaison avec toute autre information contextuelle disponible pour déterminer si l'appel actuel doit être autorisé ou rejeté. Les détails sur la façon dont un serveur de ressources effectue ces vérifications sont hors du champ d'application de cette spécification de profil.