How does a short-lived Access Token add security?

Question

In the answer to the question Why do access tokens expire?, the first point provided states:

[Bearer-Tokens are] short-lived and requiring refresh, they limit the time an attacker can abuse a stolen token.

But when an Access-Token is used (From a native-app), the Client uses the Refresh-Token to get a new Access Token, and sends that new token back to the requestor. So if an attacker uses somebody else's access token, he'll just be sent a brand new access token every time.

So who cares about how long the token lasts? If an attacker gets it, they have taken over the session For As Long As The Refresh Token Lasts

I already know a dozen answers to my question, but I have questions to each answer. My original question was so long because I explained every scenario and how they are inconsequential or false (as far as I know). So please try to help me understand and I'll comment if I think the answer has caveats.

Addition/Edit - Hoping for more answers with my additional information

1. Web Page calls a Client with Resource Owner (User) Credentials
2. Client calls the Auth Server and gets an Access and Refresh Token. The Access Token will expire in 5 minutes, the Refresh Token will expire in hours or days or whatever.
3. Client sends the Access Token to the Web Page
4. Resource Owner (User) uses the web page
5. Web Page sends the Access Token to the Client
6. Client sends the Access Token to the Resource Server
7. Resource Server checks the Access Token in any number of ways
8. Resource Server sends Resources to the Client
9. Client sends Resources to the Resource Owner
10. Resource Owner (user) Continues to use the Web Page
11. The Client, either during Each Request or every 4 minutes and 30 seconds, uses the Refresh Token to get a new Access Token
12. The Client, either during Each Request or every 4 minutes and 30 seconds, sends a New Access Token to the Active Resource Owner

Yes? No? Since the Resource Owner is Actively using the web site, the web site is in constant communication with the Client, and the Client gets a new Access Token (Using the Refresh Token) and sends it back to the web site, so the Active user can continue using the site without being kicked out every 5 minutes.

Therefore, if ANY Person gets ahold of that Access Token, and are hitting the Client with it, the Client will continue to send new Access Tokens to whoever has that Access Token. Granted: After a single refresh, one of those two people will have a bad Access Token and be booted, but not necessarily the right person.

Answer 1

Your point seems to be that if an attacker can take over your browser session then they will be able to access the third-party resource for the entire length of the refresh token, as you've described. So what's the point of having a short-lived access token?

There's certainly some truth to that, but there are two general responses:

• Using a refresh token makes it practicable to invalidate the user if the third-party figures out that the session has been taken over by an attacker.
• The access token / refresh token system is used to prevent or limit other kinds of attacks that you haven't mentioned.

Regarding the first point, remember that the access token is sent to the resource server, not the authorization server. Although there's nothing in the specification that prevents the resource server from checking the validity of the user, in practice that could present performance issues. Access tokens are typically designed to be self-validating, without requiring access to some external resource.

Given that, the only way to invalidate a user is to do it on the authorization server when the refresh token is sent in. The authorization server sees that this user has been marked as compromised, and refuses to send a new access token.

Regarding the second point, there are plenty of other security scenarios that OAuth is designed to protect against other than a user's browser session being taken over by an attacker. What if someone is able to get ahold of the access token in some other way? Since the access token itself isn't generally used to get access to the client (see below), they won't be able to get the client to refresh the token for them, and therefore the fact that the access token is short-lived will be a security advantage.

As a reference, both of these points are made succinctly in this email to the Oauth Working Group mailing list.

---

Looking specifically at the flow you described in your post, I think your confusion is rooted in the idea that the client (web server) sends the user agent (the browser) the access token (your step 3), and that that token (in the form of a cookie) is what the client uses to authenticate the user agent. Although it's possible for a web framework to do those things, neither one is a part of OAuth (nor generally true of web frameworks, in my experience).

Answer 2

Access tokens are short-lived, refresh tokens are long-lived. Access tokens are presented to the Resource Server (and only the Resource Server) that hosts the protected content to get access. Refresh tokens are presented only to the Authorization Server, never to the Resource Server. So when an attacker obtains an access token, he can use it for the lifetime of the access token to get access to the protected content.

When the access token expires there's no way to get a new one unless he has obtained the refresh token as well. Besides that, when using the refresh token the client typically authenticates itself to the Authorization Server, so even when the attacker got the refresh token, he would also need the Client's credentials to use it to get a new access token.