1

My server sets cookies with the JWT and refresh tokens on login, and likewise when the refresh route is hit. If a valid JWT cookie is found in the request for these routes, should a new one be issued? If so, should the old be blacklisted? And if not, what would be a valid response code?

1 Answer 1

0

Use Case

Lets say you have two endpoints /secure and /token

Hitting /secure with a valid access_token, returns 200 Success

Hitting /secure with an invalid access_token, returns 401 Unauthorized

Hitting /token with a valid refresh_token, returns a new access_token and refresh_token and this should remain consistent, regardless of wether the access_token is valid or invalid.

Refresh Tokens Lifecycle

It is best to invalidate the previous refresh token. This is because you do not want more refresh tokens then there needs to be. It is very important that the refresh token is stored securely if it is going to remain valid for a long time.

Access Tokens Lifecycle

Usually the lifecycle of the token is determined by its expiration date.

If it was a requirement to invalidate old access tokens, then you would have to persist an identifier for them, and check that each time you received a token.

This removes the stateless nature of using JWT in this way, but eliminates the same user having multiple access tokens, the reuse of a previously blacklisted token, or replay attacks.

Design Concerns

In this architecture, you want a separation of concerns between the access_token and refresh_token, wherein the refresh_token is uses for (re)authentication and the access_token is used for authorization.

This means that if you do blacklist access tokens it should be handled by the /secure endpoint, because only it is in charge of its authorization (who is allowed to do what).

The use case for refresh and access tokens using JWT, avoids the need for cookies, allowing authentication and authorization with different clients: SPAs, Mobile Apps, Web Apps, Desktop Apps, other servers etc. that may not have the use or access to cookies to persist session data.

If you stick strictly to the design pattern, then you would avoid cookies all together. If you use cookies, the the answer to your question is: you probably shouldn't use cookie when hitting /token.

If you use the cookie in /token you could end up not creating a new access token when an old one is about to expire and the call was intentional, or have some complex logic to determine when to generate a new access token. Or even worse, not use the JWT access token to determine its own lifecycle.

Appendix

For checking the time based validity of the JWT access_token:

I recommend you utilize the "exp" claim in the JWT. This would be a good baseline determining factor to expire the tokens. Referenced in Section 4.1.4 of RFC 7519. But if you are putting the token inside of a cookie, you could also have the cookie expire after a certain amount of time

For blacklisting certain access_tokens:

Section 4.1.7 mentions the "jti" claim which could be used for black listing tokens with certain identifiers.

3
  • I might not have been very clear in the question, but I was asking more around what to do if a user is trying to hit the login or refresh route, and I detect that they have a valid jwt cookie in the request already. I.E. they’re trying to log in while already logged in. Should the API just return the same set of cookies? Should it issue new ones but revoke the old ones (I have this capability), or should it throw an error?
    – Andre C
    May 12, 2020 at 22:02
  • @AndreC I assumed your question was around JWT, which has a different purpose than session cookies. JWTs are to maintain the integrity of a claim from one server to the next, i.e. "Hey server B, I just came from server A, and they said I could do X". Session cookie are generally to be used within realm of a domain, i.e. "Hey server B, I have this session cookie, can I still use it?". Let me update my answer to address those specific points.
    – iraleigh
    May 12, 2020 at 23:10
  • @AndreC I have edited my answer. Sorry for the confusion
    – iraleigh
    May 13, 2020 at 1:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .