8

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.

Community
  • 1
  • 1
Suamere
  • 4,460
  • 1
  • 37
  • 47

2 Answers2

5

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

Kevin Christopher Henry
  • 37,093
  • 5
  • 98
  • 87
  • Seems to me that OAuth Access/Refresh token security hinges on the ability to detect when a token has been compromised. Then the Refresh Token can be cancelled. But that seems insufficient because detecting when a token has been compromised is complicated against any planned attacker with basic security knowledge. Seems like the only way to protect against it is a constant handshake with rolling keys, and if an old key is ever attempted to be exchanged because the handshake gets out of sync, cancel the Refresh Token. – Suamere Jul 15 '16 at 15:17
  • @Suamere: No security technique can protect against all attacks, but as demonstrated this increases the security relative to a long-lived self-validating access token, which was your question. Many companies (Google, Facebook, credit card companies, etc.) have automated systems in place to detect abusive and fraudulent use of their services, so it's certainly possible to detect bad actors and invalidate their tokens. – Kevin Christopher Henry Jul 15 '16 at 22:10
  • So scalability and protection against websites that don't follow best practices. The latter I'm not concerned about, but is the scalability optimization something that most people are okay with (e.g., allowing attacker to access the API for at most one hour)? In other words, is this simply an extra layer of security on top of an already secure protocol (https, csrf, xss protection, etc)? – user1164937 Aug 14 '16 at 06:14
  • @user1164937: I suppose most people are okay with it since it is a very widely-used protocol! Not everyone, though. In this [post](https://hueniverse.com/2010/09/29/oauth-bearer-tokens-are-a-terrible-idea/), the original lead author of the OAuth2 specification (he later resigned) argues that relying on SSL to protect bearer tokens is a "terrible idea". – Kevin Christopher Henry Aug 14 '16 at 07:43
  • @KevinChristopherHenry Right, and the amount of information the attacker can access is already limited to the user's permissions (e.g., viewing the user's Facebook profile). However, would you ever use this method for your internal website (e.g., Facebook) using a JWT in place of an acess token? Or would you just stick to regular stateful sessions? – user1164937 Aug 15 '16 at 19:32
  • "Although there's nothing in the specification that prevents the resource server from checking the validity of the user, in practice that would present performance issues" That last part sounds a lot like speculation without any reasoning. Depending on your architecture and infrastructure you might encounter these problems, but that's not a given. – BluE Mar 18 '21 at 21:05
0

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.

Hans Z.
  • 41,402
  • 9
  • 80
  • 105
  • 1
    Right. So if an Access Token only lasts 5 minutes in a Browser-Secure HTTPS-Only cookie on my website... how come you aren't logged off after 5 minutes? And why does the cookie value constantly change? The answer is because: The Web Server (Client) is constantly refreshing the token for free and sending a new cookie back. So as an attacker with **YOUR** Cookie, I just send it once to the web server and it will consistently give me a NEW Access Token. – Suamere Jan 21 '16 at 22:03
  • You are conflating tokens with cookies and in general conflating OAuth clients with web applications that authenticate users; an article that goes in to the distinction: http://oauth.net/articles/authentication/ – Hans Z. Jan 22 '16 at 08:11
  • 1
    I can see how that is commonly the case, but I don't believe that is what I'm doing. I have previously read that article and, also, I understand OAuth too much to have done that. I am indeed saying the Server-Side Web Application is the Client in this story. But I am not confusing it with an authentication process. I am also indeed saying that using cookies to store the Access Token is the method being used, though that is not the only way. My question and comments are *specifically* about the authorization sequence of OAuth, and the Access/Refresh tokens' relationship. All OAuth stuff. – Suamere Jan 22 '16 at 15:28