Comment puis-je révoquer un JWT token?

En général, le la réponse la plus simple serait de dire que vous ne pouvez pas révoquer un token JWT, mais ce n'est tout simplement pas vrai. La réponse honnête est que le coût de soutenir la révocation JWT est suffisamment grand pour ne pas valoir la plupart du temps ou simplement reconsidérer une alternative à la JWT.

cela étant dit, dans certains scénarios, vous pourriez avoir besoin à la fois de JWT et d'une révocation immédiate du jeton, alors passons en revue ce que cela prendrait, mais d'abord nous allons couvrir certains concept.

JWT (Learn JSON Web Tokens) spécifie juste un format de jeton, ce problème de révocation s'appliquerait également à tout format utilisé dans ce qui est généralement connu comme un jeton autonome ou de sous-valeur. J'aime cette dernière terminologie, parce qu'elle contraste bien avec les signes de référence.

jeton de valeur - les informations associées, y compris la durée de vie du jeton, sont contenues dans le jeton lui-même et l'information peut être vérifiée comme suit: provenant d'une source fiable (signatures numériques à la rescousse)

jeton de référence - l'information associée est conservée sur le stockage côté serveur qui est alors obtenu en utilisant la valeur du token comme clé; étant le stockage côté serveur, l'information associée est implicitement fiable

avant le Big Bang JWT nous avions déjà traité des tokens dans nos systèmes d'authentification; il était courant pour une application de créer un identifiant de session sur l'utilisateur connexion qui pourrait ensuite être utilisé de sorte que l'utilisateur n'a pas dû répéter le processus de connexion à chaque fois. Ces identificateurs de session ont été utilisés comme index de clés pour le stockage côté serveur et si cela ressemble à quelque chose que vous avez récemment lu, vous avez raison, cela classifie en effet comme un jeton de référence.

en utilisant la même analogie, comprendre la révocation pour les tokens de référence est trivial; nous supprimons simplement le stockage côté serveur associé à cette clé et la prochaine fois que la clé est fournie sera pas valide.

pour les tokens De by-value nous avons juste besoin de mettre en œuvre le contraire. Lorsque vous demandez la révocation du jeton, vous stockez quelque chose qui vous permet d'identifier de manière unique ce jeton afin que la prochaine fois que vous le recevez, vous puissiez vérifier en plus si il a été révoqué. Si vous pensez déjà que quelque chose comme ça ne va pas se mettre à l'échelle, ayez à l'esprit que vous avez seulement besoin de stocker les données jusqu'au moment où le jeton expirerait et dans la plupart des cas, vous pourriez probablement juste stocker un hachage du jeton pour que ce soit toujours quelque chose d'une taille connue.

comme dernière note et pour centrer cela sur OAuth 2.0, la révocation des tokens d'accès by-value n'est actuellement pas standardisée. Néanmoins, la révocation du Token 2.0 de OAuth précise qu'elle peut être réalisée tant que le serveur d'autorisation et le serveur de ressources acceptent une façon personnalisée de gérer cela:

Dans le premier cas (autonome jetons), certains (actuellement non standardisé) l'interaction d'arrière-plan entre le serveur d'autorisation et le serveur ressource peut être utilisée lorsque la révocation immédiate du token d'accès est souhaitée.

si vous contrôlez à la fois le serveur d'autorisation et le serveur de ressources, c'est très facile à réaliser. D'un autre côté, si vous déléguez le rôle de serveur d'autorisation à un fournisseur cloud comme Auth0 ou à un composant tiers comme Spring OAuth 2.0, vous aurez très probablement besoin d'aborder les choses différemment car vous probablement seulement ce qui est déjà standardisé.

Une référence intéressante

Cet article d'expliquer d'une autre façon de le faire: Blacklist JWT Il contient quelques pratiques intéressantes et le modèle suivi par RFC7523

Voici une solution appelée JWT ancien pour le nouveau schéma exchange.

parce que nous ne pouvons pas invalider le jeton émis avant la date d'expiration, nous utilisons toujours le jeton à court terme, tel que 30 minutes. Lorsque le jeton expiré, nous utilisons l'ancien jeton échange d'un nouveau jeton. Le point critique est un vieux jeton peut échanger un nouveau jeton .

Dans le centre auth server, nous maintenons un tableau comme ceci:

table auth_tokens(
    user_id,
    jwt_hash,
    expire
)

user_id contenu dans JWT chaîne. jwt_hash est une valeur de hachage de la chaîne entière JWT,telle que SHA256. expirer champ est facultatif.

La suite est flux de travail:

1. demande de l'Utilisateur le login API avec le nom d'utilisateur et le mot de passe, l'authentification du serveur enjeu d'un jeton, et d'enregistrer le jeton ( ajouter une ligne dans le tableau. )
2. lorsque le token a expiré, l'utilisateur demande L'API d'échange avec l'ancien token. Tout d'abord le serveur auth valide l'ancien token comme normal sauf la vérification d'expiration, puis crée le valeur de hachage du jeton, puis recherche au-dessus de la table par ID utilisateur:
   • si find record et user_id et jwt_hash correspondent, alors lancez un nouveau token et mettez à jour la table.
   • si l'enregistrement est trouvé, mais user_id et jwt_hash ne correspondent pas , cela signifie que quelqu'un a utilisé le nouveau token échangé auparavant. Le token doit être piraté, supprimer des enregistrements par user_id et répondre avec des informations d'alerte.
   • si l'enregistrement n'est pas trouvé, l'utilisateur doit se reconnecter ou entrer seulement le mot de passe.
3. lorsque l'utilisation a changé le mot de passe ou la connexion, supprimer l'enregistrement par ID utilisateur.

pour utiliser un token en continu, l'utilisateur légal et le pirate ont besoin d'échanger un nouveau token en continu, mais un seul peut réussir, si l'un d'eux échoue, les deux doivent se reconnecter au moment de l'échange suivant.

donc si hacker a obtenu le token, il peut être utilisé pour une courte période, mais ne peut pas échanger pour un nouveau si un utilisateur légal A échangé un nouveau la prochaine fois, parce que le token période de validité est de courte durée. Il est plus sûr de cette façon.

S'il n'y a pas de hacker, l'utilisateur normal a aussi besoin d'échanger un nouveau token périodiquement ,par exemple toutes les 30 minutes, c'est comme se connecter automatiquement. La charge supplémentaire n'est pas élevée et nous pouvons ajuster le temps d'expiration pour notre application.

source:http://www.jianshu.com/p/b11accc40ba7

ceci ne répond pas exactement à votre question en ce qui concerne le cadre du ressort, mais voici un article qui explique pourquoi si vous avez besoin de la capacité de révoquer JWT, vous pourriez ne pas vouloir aller avec JWT en premier lieu, et à la place utiliser des jetons porteurs réguliers et opaques.

https://www.dinochiesa.net/?p=1388

une façon de révoquer une JWT est de tirer parti d'un système d'événements distribués qui informe les services lorsque les jetons de rafraîchissement ont été révoqués. Le fournisseur d'identité diffuse un événement lorsqu'un jeton d'actualisation est révoqué et d'autres backends/services écouter l'événement. Lorsqu'un événement est reçu, les backends/services mettent à jour un cache local qui maintient un ensemble d'utilisateurs dont les tokens de rafraîchissement ont été révoqués.

ce cache est ensuite vérifié chaque fois qu'une JWT est vérifiée pour déterminer si la JWT devrait être révoqué ou non. Tout cela est basé sur la durée des JWTs et l'instant d'expiration des JWTS individuels.

Cet article Révocation JWTs, illustre ce concept et dispose d'un exemple d'application sur Github.