[jon-wood]

Something I’ve never really got about refresh tokens is how they improve that situation - I have difficulty seeing a situation where the access token can be compromised but the refresh token can’t, and with a refresh token you’re free to request new access tokens indefinitely.

[adsjhdashkj]

I think it's more like when you use the refresh token, there's a surface area of attack - lets say it's a login server. If the login server is the only one to ever get refresh tokens, then that's the only surface area where refresh tokens can be breached, audited, etc.

Every other API gets a short lived access token. While that also needs to be secure, the vulnerabilities of that become different. Eg if your logs printed your access tokens, and after 30 days you moved them to S3, no one could read the S3 logs and log into your service. Probably a terribly insecure example but i think it illustrates the different vectors to be concerned about. Refresh tokens vs Access tokens just have different surface areas to be concerned about.

[jon-wood]

Thanks, that makes a lot of sense - I was thinking in terms of the ultimate client application being compromised, which isn't helped by refresh tokens, but hadn't considered that services along the way don't ever see those tokens.

[atmartins]

In a complex application I'd rather send a very short lived and tightly scoped token to a service written by another team or another company that I know less about.

If the service handling your access token has some security issues (old version of x y z, etc) there is limited damage if nefarious actors acquire that token. They could not keep your session alive, spread horizontally, etc. Also, you can make access tokens very short lived to minimize the window of opportunity, should someone acquire one.

Then I can concentrate on my "session service" (the thing issuing tokens) to be very secure, and tune the characteristics of either token as needed.