[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.