Giuseppe Ciaccio, Antonio Pastorino and Marina Ribaudo
the AS after obtaining consent from the resource owner, and is delivered to the client through the browser of the resource owner via HTTP redirection( see the Figure).
In the current IETF draft, TLS protection is not required when the AS redirects the browser to the client after the authorization step; in other words, it is legal for the client redirection URI( Figure 2) to be an HTTP endpoint of the web application instead of an HTTPS one. On the one hand, this shortcoming is meant to cover client applications that are unable or unwilling to provide TLS endpoints( due to lack of resources, for instance). On the other hand, an authorization code sent to a non‐TLS endpoint is transmitted in plain text and could therefore easily be eavesdropped. The stolen authorization code could then be used by an attacker client to obtain an access token from the AS. But if the client application has a persistent identity registered at the AS, that is, it shares a secret with the AS and can prove that it holds it( a“ confidential” client, in the OAuth jargon), then the AS will prompt the client application to authenticate before converting the authorization code into an access token, thereby preventing the use of stolen authorization codes. As an additional security measure, the access token itself may be bound to the specific client identity( a so called“ proof token”( IETF 2012 a), as opposed to an anonymous“ bearer token”). In contrast, if the client does not hold a secure and persistent secret registered with the AS( a so called“ public” client) then the flow is insecure, unless the client redirection URI is an HTTPS endpoint.
A security analysis of OAuth 2.0 is beyond the scope of this paper, and can be found in a dedicated IETF draft( IETF 2012 a).
Figure 2: OAuth 2.0 authorization code flow, for web applications. The“?” denotes an HTTP GET parameter
From the above it is reasonable to deduce that resource owners( users), clients, and RSs should establish a relation with the AS before engaging in any OAuth 2.0 protocols. The current IETF draft explicitly leaves out of scope( but does not forbid) any interaction between an RS and the AS, and seemingly ignores the registration of resource owners, although this is indeed a necessary step if the AS is to issue authorization grants on their behalf. Only client registration to AS is explicitly mentioned in the IETF draft. After registration, the client is given a unique identifier that is valid at the AS.
139