2

What's the standard best-practice approach for coordinating the browser/user agent session with the client in the OAuth 2.0 Authorization Code Flow?

In the OAuth 2.0 Authorization Code Flow, the client (Web application you are using) gets an access token directly from the Authorization Server. The access token is never exposed to browser/user agent, one of the important benefits of Code Flow. The client security preserves the access token (and refresh token, if provided) so that it can reuse it for subsequent requests from the user (via the browser/user agent.)

That leads to a question: How do the client and the browser/user agent convey the user's session, so that the client "knows" which access token to use on behalf of the user, and that it's okay to do so?

I've found sample code in which the client creates a session cookie for the browser/user agent. That works, but seems to reopen the door to cookie-based exploits. There are standard approaches to prevent them, but I thought that one benefit of OAuth 2.0 is to avoid those attacks altogether. (Besides, we're hosting a Web REST API, so there are no forms to POST, and I'd like to keep the API interface clean, simple, and based on standard security approaches.)

Notes:

  • The OAuth's tokens and sessions in REST doesn't actually answer this particular question, although I, too, love Greg Beech's response.

  • The question Understanding OAuth and client sessions has a similar intent, but the answer does not apply to our case.

  • This question is about subsequent requests from the user agent, not about the callback handler.

  • We fully expect and intend that our REST requests will not be stateless, and that client-side will maintain state information for the user's session. For very good reasons that I would rather not enumerate here, we are not making a stateless REST interface.

Community
  • 1
  • 1
Dan Konigsbach
  • 153
  • 7

1 Answers1

1

I will re-state your question in the way I think I understand it. The benefit of the OAuth2 Authorization Code Flow is that the sensitive access token is not passed through the user-agent and is thus not subject to security holes at the user-agent. Well, if security holes at the user-agent is a concern, then why should the client use cookies to maintain a session with the user-agent? Shouldn’t the client use an alternate mechanism to maintain a session with the user-agent?

Well, here’s my answer ...

I believe the best practice is still cookies for a web app OAuth client to maintain a session with a user-agent. Cookies have well-known security properties. But OAuth access tokens serve a different purpose than cookies.

I don’t think OAuth2 was meant to mitigate cookie-based exploits. The main purpose of OAuth2 is to allow users to delegate access to their data to clients without exposing user credentials to the clients. Also, with OAuth Implicit Flow, access tokens are exposed in the user agent in ways that cookies are not.

Cookie-based exploits can certainly allow an attacker to masquerade as a user and cause a web app OAuth client to use its access token(s) to access user data at an OAuth resource. However, the user himself/herself is the main attack vector in cookie-based exploits (ex: user visiting a malicious site that executes XSRF/CSRF). But it’s not the job of the OAuth authorization server to protect against that. It’s the job of the OAuth authorization server to ensure that the right client gets the right access token, based on user consent.

E Anwar Reddick
  • 36
  • 5
  • Thank you for a very reasonable and thoughtful response. Yes, you understand the question, and I think you've covered the topic well. – Dan Konigsbach Apr 15 '15 at 23:12