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:

source:  http://tutorials.jenkov.com/oauth2/roles.html

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.