2

I have some questions (more so confusion) about the use and or the reason behind refresh tokens when I'm using jsonwebtokens.

Firstly, why is it even needed? I fully understand the whole thing about short lived access tokens and long lived refresh tokens that are used to acquire new access tokens, but then I feel like that leaves the refresh token just as vulnerable and maybe more then normal access tokens

Secondly I hear people saying stuff about how the Resource server cares about the access token and the Authorization server cares about the refresh token. but I have 1 server just an API that I'm using jwt's to authorize and authenticate with

also yes, I do understand that its better experience for user because they can stay logged in for longer etc, but the question still rises why not just make the access token last a long time?

My question boils down to, why exactly are they needed / used and what makes them more secure then just using access tokens?

Nimantha
  • 6,405
  • 6
  • 28
  • 69
Skyler Brandt
  • 97
  • 1
  • 1
  • 4
  • 1
    neither the token nor the refresh should be vulnerable, then the length of your expiry or if you expire in 30seconds or 30months depends on if it matters to your app, that's why there is an option to change it, short-lived tokens are useful if you utilise roles part or any other meta, or if your site has XSS and all tokens are captured, then you fix the issue.. you wouldn't want 30month old tokens to still work. – Lawrence Cherone Oct 04 '21 at 08:00

1 Answers1

0

A long-lived token is needed if users shall be kept logged in to your service, for example via a mobile app, without having to repeat their consent over and over again. On the other hand, users must be able to revoke their consent (for example, after losing their mobile phone) or reduce its scope (for example, if the authorized app shall no longer be able to write to their service account, only read from it).

This means that before accepting a request, the server must not only validate the token but also verify that the user has not revoked it. For better performance, the two tasks are distributed between the resource server and the authorization server.

  • The resource server validates the access token. This can be done by verifying a signature, without accessing a database or so. The scope of the user consent can be contained in the access token (a claim in a JWT, say), or can be kept in a cache. This allows the resource server to quickly execute many requests without verifying the scope for each. There is a risk that a revocation of user content is not detected, but this risk is mitigated by making the access token short-lived.
  • After the short-lived access token has expired, the client making the request still has the long-lived refresh token. This must be sent to the authorization server in order to obtain a new access token, and during this step the user consent is verified again, for example, by accessing the user database. This may lead to a reduction in scope, or to no access token being issued at all. This more expensive operation happens less often than a request to the resource server.

Even if your server plays both roles of authorization and resource server, it may make sense to distribute the tasks in the same way.

Heiko Theißen
  • 12,807
  • 2
  • 7
  • 31