in Uncategorized

OAuth 2.0 and Cookie Convergence

Despite the argument by Eran that OAuth 2.0 without signatures is bad for the web, I find that OAuth 2.0 is what OAuth 1.0 should have been.

The most notable difference in OAuth 2.0 is that the token that clients use to access protected resources is exchanged like a Cookie. Consider a typical flow for Cookie-based authentication:

  • User submits a form to a resource with a user ID and password.
  • On login, the site issues the browser a token via the Set-Cookie header.
  • The browser then sends that token with all future resource requests to all resources on that server using the Cookie header. The same-origin-policy tells the client the URI space that can receive the token.

Ignoring the mechanics of how the tokens are represented in HTTP, the OAuth 2.0 flow for browser-based clients is similar.

  • User submits a form granting access to the client. This step may include login. This is similar to submitting a login form.
  • The site issues the client (an app) a token (the Access Token) as part of the response body.
  • The client then sends that token with all future resource requests using the Authorization header. This is similar to sending a Cookie header.

Here is the difference. There is nothing in the OAuth 2.0 protocol to guide the client to say what URIs the client is allowed to send the access token to. The client is just supposed to know the URIs that the token is valid for, and ensure to not exchange the token with other servers. In OAuth 1.0 this is not an issue since, as instead of sending the raw access token, the client sends a signature of the token. The signature includes a nonce and a timestamp to prevent man-in-the-middle attacks. OAuth 2.0 does not have the same protection, just like Cookie-based authentication.

Eran argues that this is as bad as Cookie based authentication. True. However, in the interest of interoperability and ease of use, OAuth 2.0 is a step in the right direction.

If you are offering resources that support OAuth 2.0 and are concerned about replay or man-in-the-middle attacks, issue short-lived access tokens and use TLS. As far as I am aware, except for Yahoo!, no other OAuth 1.0 implementors offer short-lived access tokens or a way to renew expired access tokens. This needs to change. OAuth 2.0 specifies how to refresh access tokens when they expire.

There is another unintended consequence of OAuth 1.0. Since OAuth 1.0 resource requests include a nonce and a timestamp, resource developers tend to ignore basic concurrency control mechanisms in HTTP. Recently one developer argued with me that the signature protects his code from having to deal with duplicate POSTs. But there are other ways to deal with that, and forcing signatures on clients is a bigger hammer than necessary.

PS: Thanks to JJ for asking me about this for his post on infoQ.

PPS: I do not claim to be a security expert. Caveat emptor!

Write a Comment

Comment

  1. Are you not talking right past Eran?

    Summarizing using his words in another post (addressing being misunderstood elsewhere too):
    “My post was about discovery and long term security improvements of the web”

    While, summarizing using your words:
    “However, in the interest of interoperability and ease of use, OAuth 2.0 is a step in the right direction”

    I’m struggling to see why you setup and address a straw man.
    Does it mean you don’t think the use case Eran is concerned about matters in the future? (He indicates clearly, via a section heading, ‘Why None of this Matters Today’)

    • I don’t follow your comment. The client, as the bearer of a token, has some responsibilities. In this case, it is not giving up the access token to some rogue server (the same as not posting some confidential data to the wrong server).

      As far as discovery is concerned, any discovery protocol should be hypertext based so that the issuer of the token tells the client when and to where it must send the access token. I don’t see (yet, given that there is no discovery spec on the table) how discovery is precluded by lack of a signature.

      • OK this may clarify?

        I think you provide a contemporary state-of-play defense/argument to refute Eran’s concerns:
        “Eran argues that this is as bad as Cookie based authentication. True. However, in the interest of interoperability and ease of use, OAuth 2.0 is a step in the right direction.”

        Whereas, I thought Eran, while acknowledging the benefits you point to, raises a forward looking objection:
        “The problem with this argument is not today, but 5 years from now. When trying to propose a new cookie protocol, developers will make the same argument, only this time pointing the finger at OAuth 2.0 as the weakest link. ”

        I’m not sure anyone argues that discovery is precluded by the lack of signature – or at least I haven’t read that argument.
        Rather, Eran’s seems concerned that future security improvements will be resisted by pointing to OAuth 2.0 as the weakest link in the security chain.
        Furthermore, insecure/badly-designed discovery is more likely to be exposed. For example, to make a ridiculous/extreme case: If a token must be signed, then I don’t risk suffering when someone works out that some token leaks information.

        I really read Eran’s post as a plea to maintain the momentum of, incremental, improvements to the links in the web’s chain of security. Whereas you don’t address that issue. Instead, talking past Eran’s and addressing an ease-of-use straw man.
        No?

  2. Hello,
    Please forgive my naivety but i’m a newbie to security. My question is as follows:
    I am using Windows Azure ACS to issue a swt token based on a relying party url (the realm) then the token issued is for that realm. In addition the token is signed with a symmetric key that only the relying party application will have. In addition im using the WIF OAuth extensions to retrieve the swt token from ACS using the OAuth2.0 endpoint. My understanding is that once the swt token has been signed using a 256bit symmetric key (configured in ACS) – then only an application (a web based api in my case) with the correct signing key will be able to correctly decrypt and validate the token. This is actually the setup i have at the moment – pls could you comment on this.

    Thank you.