Giuseppe Ciaccio, Antonio Pastorino and Marina Ribaudo
OAuth stems from a typical Web 2.0 use case with online social networks. Suppose a third party client application is offering a user a personalized service making use of that user ' s personal features provided by a social network( e. g. pictures, contact list, posting a comment) via a RESTful API. The naive approach of requiring users to release their credentials( username and password) to the third party client so that the latter could get those features from the social network is highly risky. A more appropriate solution is to release cryptographic proof of authorization, issued by the user( at least in principle) to the third party application, and to let the latter subsequently spend such authorization proof at the social network API in order to get the required features. In addition, the authorization proof may work as a form of user authentication whenever it grants access to user identification data stored in the social network or elsewhere.
Abstractly, OAuth 2.0 identifies four actors exchanging information in an ordered way( Figure 1). These actors are the client application or just“ client”, the resource owner or“ owner '” for short( or“ user” when human), an authorization server( AS, the trusted entity), and one or more resource servers( RS) hosting data or services to be smartly disclosed. The AS and the various RSs may each belong to a distinct administration domain, but this is not mandatory.
Figure 1: OAuth 2.0 abstract protocol, with the four OAuth 2.0 actors( client application, resource owner, authorization server, and resource server) and their interplay. Actions are ordered by increasing number
The protocol is started by the client asking for authorization to access a given resource( e. g. a set of personal data), subject to a set of constraints called scope( e. g. read vs. write access to specific fields of personal data during a specified time window). The resource owner is shown the request and, if they agree with the scope, they may yield an authorization grant bound to the resource and scope. Such a grant is then exhibited by the client to the AS, which validates it and returns an access token valid for the required resource at a specific RS subject to the scope. The client finally passes the access token to the given RS along with the resource request; upon token validation and scope verification, the RS returns the resource to the client.
In practice, the authorization grant can be obtained in four possible ways. These four ways are called flows in OAuth jargon( IETF could not call them“ protocols” due to the many details that are omitted or left undefined), and are nothing but instantiations of the abstract protocol scheme discussed above. Due to a lack of space we herein only describe the first and most important of the flows; anyone who may be interested is advised to consult the IETF specifications( IETF 2012 b) or our technical report( Ciaccio 2013).
In such flow the grant is obtained indirectly, with the AS acting as an intermediary under the control of the resource owner. The flow is depicted in Figure 2. With this flow, the client is typically( but not necessarily) a web application on a remote server, and the resource owner is typically( but not necessarily) a human with a browser initially pointed to the web application. The grant is represented by an authorization code issued by
138