3 ms·

Probably a silly question, but how exactly does the refresh token help here? If your app is keeping the tokens accessible from javascript, then an attacker who

Probably a silly question, but how exactly does the refresh token help here? If your app is keeping the tokens accessible from javascript, then an attacker who (through XSS for example) can steal the short-lived access token could also steal the long-lived refresh token an "trade it" for a new access token, no?

tiziano88 6y ago
Usually the refresh token would be kept server side only
windowsworkstoo 6y ago
Refresh token rotation seems to be the standard mitigation (https://auth0.com/docs/tokens/refresh-tokens/refresh-token-rotation https://auth0.com/docs/tokens/refresh-tokens/refresh-token-r...)
- tftyeti 6y ago
  Sure, that mitigates the risk when an attacker finds a refresh token later and it's no longer valid because of rotation. And it means that a stolen refresh token would probably be noticeable because the legitimate user wouldn't be able to use it anymore. But in many attack scenarios the attacker would get the refresh token immediately and the time until discovery would be enough for them to cause damage, right?
  - dwaite 6y ago
    Generally there is a big overlap between attack scenarios that allow for token exfiltration and attack scenarios that allow for code injection. Someone doesn't need to exfiltrate a token to make the client do their malicious requests right on the user's device. And certain external mitigations, like anomalous API usage detection, won't see odd time-of-travel restrictions based on the estimated geolocations of two different IP addresses or a change in the user agent behavior (different user-agent header, different networking stack behavior, etc). The difference is that some people argue that one of them is in scope for security measures, while the other is out of scope.
mooreds 6y ago
> If your app is keeping the tokens accessible from javascript... Great question. I should have been clearer. If you use the implicit grant, you can't use the refresh token (there are work arounds like the silent refresh, though). So it's not an applicable question. With the application code grant, you have other options. Refresh tokens, like all tokens, should be treated with care and not exposed to javascript. As a sibling comment noted, you can do that by storing it server side. Sure, someone could steal your session and try to access protected resources through the server side code, but that's harder to do than stealing an access token and being able to present a bearer token to any protected resource. (Or a refresh token, which can then be presented to an IdP and exchanged for an access token.) One other option we recommend is sending down the access and refresh tokens as secure, httponly cookies. In that case, you are relying on the browser's cookie security to protect against XSS attacks. This, while not perfect, is pretty darn good, and if there's a widespread XSS cookie vulnerability: 1. Everyone with a browser client will probably have issues. 2. You could invalidate all the refresh tokens at an IdP. Pain in the but for users, but this is similar to what GitHub did earlier this month.

tiziano88 6y ago

Usually the refresh token would be kept server side only

windowsworkstoo 6y ago

Refresh token rotation seems to be the standard mitigation (https://auth0.com/docs/tokens/refresh-tokens/refresh-token-rotation https://auth0.com/docs/tokens/refresh-tokens/refresh-token-r...)

tftyeti 6y ago
Sure, that mitigates the risk when an attacker finds a refresh token later and it's no longer valid because of rotation. And it means that a stolen refresh token would probably be noticeable because the legitimate user wouldn't be able to use it anymore. But in many attack scenarios the attacker would get the refresh token immediately and the time until discovery would be enough for them to cause damage, right?
- dwaite 6y ago
  Generally there is a big overlap between attack scenarios that allow for token exfiltration and attack scenarios that allow for code injection. Someone doesn't need to exfiltrate a token to make the client do their malicious requests right on the user's device. And certain external mitigations, like anomalous API usage detection, won't see odd time-of-travel restrictions based on the estimated geolocations of two different IP addresses or a change in the user agent behavior (different user-agent header, different networking stack behavior, etc). The difference is that some people argue that one of them is in scope for security measures, while the other is out of scope.

mooreds 6y ago

> If your app is keeping the tokens accessible from javascript... Great question. I should have been clearer. If you use the implicit grant, you can't use the refresh token (there are work arounds like the silent refresh, though). So it's not an applicable question. With the application code grant, you have other options. Refresh tokens, like all tokens, should be treated with care and not exposed to javascript. As a sibling comment noted, you can do that by storing it server side. Sure, someone could steal your session and try to access protected resources through the server side code, but that's harder to do than stealing an access token and being able to present a bearer token to any protected resource. (Or a refresh token, which can then be presented to an IdP and exchanged for an access token.) One other option we recommend is sending down the access and refresh tokens as secure, httponly cookies. In that case, you are relying on the browser's cookie security to protect against XSS attacks. This, while not perfect, is pretty darn good, and if there's a widespread XSS cookie vulnerability: 1. Everyone with a browser client will probably have issues. 2. You could invalidate all the refresh tokens at an IdP. Pain in the but for users, but this is similar to what GitHub did earlier this month.