0

Hi guys I'm new to concept of refreshing token.

But I see it is a standard today.

I'm building a React/Node app and I see in a lot of articles like here, that we should send additional request to server to refresh token

Like here: https://medium.com/@monkov/react-using-axios-interceptor-for-token-refreshing-1477a4d5fc26

My Question is if we have middleware to check if access token is valid from cookie, why if token is invalid server returns 401 status, that access token is invalid, and then we send additional request from front to refresh token.

Why not check tokens from cookies in middleware, and refresh token also in middleware and return new tokens, and if both are invalid return 401 status, but in tutorials in they always send additional request for refresh token

Loki
  • 1,064
  • 2
  • 26
  • 55

2 Answers2

1

When you say middleware, is that the interceptor element of Angular?? Because there are different usage concepts.

Back to your auth + refresh tokens question. That is how OAuth is supposed to work.

Most OAuth libraries do not have features to check if the refresh token is valid or not to say to you "yay, that refresh token is okay". If the OAuth library gets a refresh token, it will provide you with a new pair of auth+refresh tokens (it will, obviously, check if the refresh token is valid to proceed).

More info: RFC OAuth 2.0 about worfklow ( https://www.rfc-editor.org/rfc/rfc6749 )

And, about storing tokens on cookies:

Don't store bearer tokens in cookies: Implementations MUST NOT store bearer tokens within cookies that can be sent in the clear (which is the default transmission mode for cookies). Implementations that do store bearer tokens in cookies MUST take precautions against cross-site request forgery.

Source: OAuth 2.0 RFC ( https://www.rfc-editor.org/rfc/rfc6750 )

Community
  • 1
  • 1
Sergio
  • 769
  • 1
  • 10
  • 15
  • Thank you for your time and answer will check it out. When I say middleware I think about middleware in Node -> Express on backend – Loki Jun 24 '20 at 12:32
  • where to store tokens if not in cookies, I read that localStorage is also not recommended, also why do we need to send second request to server when in first request we can refresh token ? – Loki Jun 24 '20 at 12:40
  • 1
    It is not about storing tokens on cookies or localStorage (if you think about it, you need to store them somewhere), as far as I know both are acceptable. It is about how you communicate backend and frontend. And there is where you should not send tokens through cookies, because they are sent insecurely. You should send tokens in the body of the request (in both ways). – Sergio Jun 24 '20 at 13:55
  • I do not get your `why do we need to send second request`? You just ask for new tokens one time, once you know they've expired. – Sergio Jun 24 '20 at 13:56
1

You wouldn't want to have a middleware that auto-refreshes an expired token simply because you wouldn't want to have a token that never expires.

Technically speaking, nothing is stopping you from having a middleware that auto-refreshes expired token on your server, in fact, you don't need to code a middleware, just set the expiration date of the initial token to some very long time in the future because auto-refreshing it is just the same as making sure it never expires.

Security-wise though, you shouldn't do that. Just think of a scenario when an attacker manages to get the access token of a user; if you're auto-refreshing expired tokens, then the attacker has access to the account for life unless of course, you change the token signature - but you wouldn't know to do this.

More detials on token life-cycle here

Tunmee
  • 2,483
  • 1
  • 7
  • 13