3

I've been reading a lot about JSON web tokens lately. A big thing that I see is that to have a timeout based on last access, and not a hard timeout, you need to use a separate refresh token. The one thing I don't see is WHY.

Why would a separate token be needed? Why not just refresh a last access value in the initial token every time it's received? The initial access time can still be preserved and a longer hard timeout established regardless.

halfer
  • 19,824
  • 17
  • 99
  • 186
craigmiller160
  • 5,751
  • 9
  • 41
  • 75
  • Possible duplicate of [Why Does OAuth v2 Have Both Access and Refresh Tokens?](http://stackoverflow.com/questions/3487991/why-does-oauth-v2-have-both-access-and-refresh-tokens) – cassiomolin Sep 11 '16 at 17:08

1 Answers1

2

There are so many options on how to implement JWT and most of what it comes down to is your requirements and how you want the application to behave.

My guess is that reissuing the token every time and updating on the front end will not perform well in a large application. You have to replace the token completely because the last access time stamp is part of the payload and thus, if you change any part of the payload, the signature for the payload will be different. If it's not part of the token, it accessible on the front end and could easily be changed to allow indefinite access.

Refresh tokens are typically associated with OAuth2. Setting up an Authorization server to issue tokens provides a nice division of responsibility and abstracts out a fairly large portion of your application in well documented, standard based way. It also allows you to revoke the refresh token, making it possible to revoke access (although not immediately) of your users. Most importantly it allows you to use the same access token for each request without reissuing it.

blur0224
  • 972
  • 8
  • 26