La spécification OAuth 2.0 est extrêmement vague en ce qui concerne la forme que devrait avoir un jeton d’accès. Voyez la discussion ici.
Le jeton d’accès peut être un JWT signé (ou comment ré-inventer OpenID Connect)
La valeur true pour la constante de configuration USE_JWT_ACCESS_TOKENS provoque l’émission du jeton d’accès sous la forme d’un JWT signé.
Voici ce qu’en dit Brent Shaffer :
"vous pouvez utiliser les jetons d’accès JWT si vous avez des systèmes distribués et que vous devez valider l’authenticité d’un jeton auprès de plusieurs parties sans avoir à passer un appel réseau.
Par exemple, un jeton est attribué par le serveur d’autorisations. Ce jeton est un jeton Web JSON signé par la clé privée du serveur d’autorisations. Les serveurs de ressources (vers lesquels les appels d’API sont effectués) sont répartis dans le monde entier et exécutent plusieurs applications. Tant que les serveurs de ressources disposent de la clé publique du serveur d’autorisations, qui n’a pas besoin d’être sécurisée, ils peuvent valider les jetons rapidement sans aucun appel réseau. Les jetons n’ont même pas besoin d’être persistés."
Dans la mesure où nous avons OpenID Connect et le jeton d’identité au format JWT, cette faculté ne parait pas essentielle. Les deux méthodes présentent l’inconvénient de ne pas permettre de vérifier l’actualité de la session OIDC.
RSS 2.0