Wednesday, September 7, 2011

On why OAuth 2.0 is weak

    Recently, I have been reading up a lot on OAuth 2.0, particularly on the token formats. OAuth 2.0 supports quite a few tokens - Authorization token, Refresh token, and Access Token (apart from Authorization Grant). I think that at a high-level this is a very good approach. It creates flexibility for functional entities. However, from an interoperability perspective, the standard should (MUST, actually) focus not just on the protocol, but on the structure and semantics of those tokens. Unfortunately, OAuth 2.0 specification fails here.
    Take the Access token (which needs to be interoperable between the Authorization Server and the Resource Server). The spec clearly states that how the RS validates the access token is out of scope - what?? Imagine a situation where I am building a RS - I need to know how to validate this token, don't I need to? May be Facebook gives out one type of token and Google does another - what am I to do?
    The text from the spec says "...The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification, but generally involve an interaction or coordination between the resource server and the authorization server." Well, what is the nature of that interaction? Again left undefined.
    I understand that token is an abstract concept. However, if you look at SAML for example, tokens have been clearly defined - particularly the signature mechanism. A token in SAML terms is an assertion containing a particular statement, and carrying a signature as per SAML spec. Now, I again understand that you can use SAML assertions as tokens in OAuth, but the point is that it is not explicitly required - meaning that you can expect a SAML assertion as token, or may be some other.
    Am I mistaken?