Why can’t we just use access token with long expiry date?
For me, having a refresh token is kind of adding more complexity to our app. It is already secure when we send it using HTTPS and also set httponly flag in the cookie to prevent client side scripting, isn’t it?
I’ve asked myself the same question, and haven’t found a definitive answer, but here’s what I imagine could be the reason:
A cookie can be stolen. It’s just a text file. It might not be as easy to get your hands on one when it’s not accessible via JavaScript, but it’s not impossible.
If you now have a cookie with a very long expiration date, you give a potential attacker endless time to exploit their unauthorised access. You basically assume that httpOnly cookies are 100% safe, which they’re not.
So I think the best way to secure your application is by forcing the user from time to time (once a month) to log in with their credentials again. But I’d really like to hear an expert’s opinion on this.
1 Like
Not an expert by any means, but make heavy use of them:
- access tokens are (should be!) short-lived
- generally, once someone has an access token, the access token gives access to the resource server/s
- critically, it is generally difficult to revoke these tokens, particularly in a granular manner
- but because the access tokens are short-lived, this isn’t so much of an issue
- a valid refresh token automatically renews the access token and avoids the issue of a user needing to log back in every five minutes of whatever. If a user has a refresh token it is assumed that at one point they had valid access rights.
- refresh tokens are generated by the auth server, and are often much easier to revoke.
- so it is a way to avoid a user having to reauthenticate every time an access token expires (rather than increasing the lifespan of an access token, which is undesirable)
- and it is a way to mitigate the problem of access tokens being leaked – you also need a valid refresh token to actually do anything (of course that can be leaked as well, but anyway)
- also the two tokens can be issued from two different servers (refresh on an auth server, access on the resource server), which can help, security- and scaling-wise if it’s done correctly. The auth server needs to have secure storage, which may be slow, whereas the resource server can have very fast storage for the access tokens as they become less important from a security perspective (if leaked, auth can just invalidate the refresh tokens).
Basically, it is desirable to have multiple layers of security. Access tokens should be short lived. And the UX for that without refresh tokens is quite bad. Whether refresh tokens add much to security seems a little up in the air, but I think they make sense. Particularly if this part of the security comes in the form of seperate, isolated and well built auth and resource servers (which I would expect [hope 
] the provider I use, AWS, has)
1 Like
So if I understand correctly, conventionally access token SHOULD be short-lived and refresh token is there for the Good UX only.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.