Why is refresh token is more secure & why do we use refresh token if it can also be stolen?

Question

Suppose my user logged in and I gave him 2 tokens ; access and refresh token

access token is valid for 15 minutes and refresh token is valid for 1 week

We don't want to give them only access token valid for a long period since someone can obtain that access token and make requests with it, that's why we are making it valid for 15 minutes.

However, can't our refresh token also be stolen ? Someone can obtain our refresh token and gets an access for 1 week ? So why do we give two different tokens and implement access-refresh based token authentication if both of them are subject to danger ?

Rie

Refresh tokens can be revoked, that is the main difference. You basically force the user to ask the server for a new access token every hour and now the sever can decide whether or not to accept the refresh token. – Saragossa

@Saragossa What if we don't have refresh token and access token can be revoked? In this case what would be difference between having and not having refresh token? – Longe

@Longe then you defeat the purpose of the tokens being verifiable without contacting a central service for each request because you need to check each and every time of the token is still valid. – Saragossa

Answer 1

You're somewhat right :) and it depends on the properties of the application you use. For example, if you have a public client (e.g. an SPA running in the browser), and you give that client access to both access and refresh tokens then you indeed lose the added security the refresh token normally would give you. If the public client can refresh tokens then anyone who steals your refresh token can use it to create new access tokens. That's why SPAs usually are not given refresh tokens directly - these tokens are either kept in an http-only cookie, or the SPA would use an SSO session to refresh the access token (then no refresh token is used).

In a confidential client we can use refresh tokens more securely, as they can't be stolen that easily, and even if stolen, the attacker would also have access to the client's secret to authenticate at the refresh endpoint.

What @luk2302 said in his comment also depends on the implementation. You can have servers where it's possible to revoke both access and refresh tokens, and also servers which can't revoke refresh tokens (it's not a requirement of the OAuth RFC).

Stegosaur

Isn't the SSO sessionId an equivalent of an access token if stored in cookies? Isn't the SSO sessionId an equivalent of an access token if used to retrieve another accessToken? – Handicraftsman

You have control over sessions in your backend. You don't have control over access tokens once they're issued to clients. E.g. you can kill the SSO session when the user logs out, but you won't be able to revoke access tokens if you're using JWTs (unless you have a mechanism for blacklisting tokens but that's another thing). Also, the issuer of the SSO session and access tokens might not be the same party. E.g. you're using Google's SSO to authenticate a user and issue an access token for them. You then rely on Google's session management to refresh tokens. – Stegosaur

Why would an http-only cookie in the same browser be more secure than localStorage where your typical SPA is going to store the access token? This argument doesn't make sense to me. – Gorizia

After reading some more elsewhere, it's because it protects against the access token being stolen from localStorage in an XSS attack. The http-only refresh token can't be stolen via that vector. – Gorizia

Exactly. localStorage is susceptible to XSS attacks, http-only cookies are not. They are susceptible to CSRF and session-riding, however. Still, it's easier to protect against CSRF than XSS and the potential fallout of a CSRF breach is usually smaller than that of an XSS breach. – Stegosaur

Answer 2

Based on Sascha Preibisch's video on YT there are 2 ways the refresh token can be implemented.

• With a sliding window
• Or with a fixed lifetime

To me the sliding window makes more sense.

Then lifetime of the refresh token should be similar to the access token (minutes or hours). And the token will just be used for as long as the user is being active instead of hours or days after activity ends.

A long lived refresh token always seems like bad news to me.

Essentially the refresh token should be so that you don't need to log in twice when spending e.g. over 1hr on a website / API.

Jolenejolenta