Un jeton d'accès OAuth 2.0 peut-il être un JWT?
D'après ce que je peux dire, la spécification OAuth 2. est extrêmement vague en termes de forme d'un access token devrait prendre:
Le jeton peut désigner un identifiant utilisé pour récupérer les informations d'autorisation ou peut contenir les informations d'autorisation de manière vérifiable (c'est-à-dire une chaîne de jetons composée de certaines données et d'une signature). Des informations d'authentification supplémentaires, qui dépassent le cadre de cette spécification, peuvent être requises pour que le client utilise un jeton.
Le jeton d'accès fournit une couche d'abstraction, remplaçant différentes constructions d'autorisation (par exemple, nom d'utilisateur et mot de passe) par un seul jeton compris par le serveur de ressources. Cette abstraction permet d'émettre des jetons d'accès plus restrictifs que l'octroi d'autorisation utilisé pour les obtenir, ainsi que de supprimer le besoin du serveur de ressources de comprendre un large éventail de méthodes d'authentification.
Les jetons d'accès peuvent avoir différents formats, structures et méthodes d'utilisation (par exemple, propriétés cryptographiques) en fonction des exigences de sécurité du serveur de ressources. Les attributs de jeton d'accès et les méthodes utilisées pour accéder aux ressources protégées sortent du cadre de cette spécification et sont définis par des spécifications complémentaires telles que RFC675 .
(pas d'italique dans l'original)
Le RFC6750 lié n'offre pas beaucoup plus de spécificité. Il existe un exemple de corps de réponse HTTP qui montre:
{
"access_token":"mF_9.B5f-4.1JqM",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
Cela semble indiquer que le access_token peut être opaque ASCII texte tel qu'un codé JSON Web Token (JWT)
De mon point de vue, il semble que JWT-as-access_token possède certaines propriétés souhaitables:
Il s'agit d'une spécification connue, avec une adoption assez large et des bibliothèques clientes disponibles dans de nombreuses langues.
Il permet une signature et une vérification faciles à l'aide de bibliothèques cryptographiques approuvées.
Parce qu'il peut être décodé en JSON, il nous permettrait d'inclure des métadonnées et des informations sur le jeton dans le jeton lui-même.
Mes questions sont: premièrement, est-il permis que le jeton d'accès soit un JWT? Deuxièmement, si cela est autorisé selon les spécifications, y a-t-il des considérations supplémentaires qui feraient que l'utilisation d'un JWT comme jeton d'accès serait une mauvaise idée?
A1: L'utilisation d'un JWT comme jeton d'accès est certainement autorisée par la spécification, car la spécification ne restreint pas son format.
A2: L'idée derrière l'utilisation d'un JWT comme jeton d'accès est qu'il peut ensuite être autonome afin que la cible puisse vérifier le jeton d'accès et utiliser le contenu associé sans avoir à revenir sur le serveur d'autorisation. C'est une grande propriété mais rend la révocation plus difficile. Donc, si votre système nécessite une capacité de révocation immédiate de l'accès, un JWT n'est probablement pas le bon choix pour un jeton d'accès (bien que vous puissiez aller assez loin en réduisant la durée de vie du JWT).
Tant que le serveur d'autorisation et le serveur de ressources conviennent de la signification du jeton d'accès, peu importe leur contenu. Donc, la seule raison pour laquelle vous pourriez avoir un problème serait si vous utilisiez des bibliothèques ou des frameworks différents lors de l'implémentation de ces deux serveurs.