Wednesday, January 16, 2013

Protocol of the Month


In my previous blogpost I said I am going to explore OAuth 2.0 more in detail.

Bluntly said, OAuth 2.0 is an open source framework for online datasharing without using a username/password, but by means of access tokens.
This simplifies data sharing for a user and is also more secure, because you do not have to enter your password in a third-party site.
UMA,my pet identity protocol to test of the last two years, is build uponOAuth2.0, making it a OAuth 2.0 profile.

To understand UMA, you have to understand OAuth2.0 first.
This can get quickly technical, demotivating nontechnical users tounderstand OAuth.
This is a pity.
That's why I will discuss OAuth 2.0 and its different authorization flows in a series of blogposts.
Told in a functional way, illustrated with daily used examples like social networks.
If you want to have more technical details I recommend the IETF OAuth2.0 draft.

First,let's have a look at OAuth 2.0 and its roles.
There are four roles:

resourceowner
An entity capable of granting access to a protected resource.
When the resource owner is a person, it is referred to as an enduser.

resourceserver
The server hosting the protected resources, capable of accepting
and responding to protected resource requests using access tokens.

client
An application making protected resource requests on behalf of the
resourceowner and with its authorization. 
The term client does not imply any particular implementation characteristics (e.g.whether the application executes on a server, a desktop, or other
devices).

authorizationserver
The server issuing access tokens to the client after successfully
authenticating the resource owner and obtaining authorization.

This can be visualized like in this diagram:


OAuth 2.0 roles as defined in the specification.


Obtaining access tokens is an important part of the OAuth2.0 protocol.
This differs per interaction the OAuth2.0 roles can undertake.
An access token is an example of an authorisation grant, a credential which represents the resource owner's authorization (to access itsprotected resources) used by the client to obtain an access token.
For granting authorization in OAuth2.0 there are four grant types:authorization code, implicit, resource owner password credentials,and client credentials, as well as an extensibility mechanism for deining additional types.

The next blog series will discuss the OAuth grant types

Stay tuned for my online adventures to unravel OAuth2.0 and interact with me through my blog, Twitter and Facebook.