Monday, 9 July 2012

OAuth protocol

In my previous post I write just a small definition about what OAuth protocol is. Today I'm going to try to explain Oauth Workflow, and therefore the work that I've been doing these last two weeks.

First of all, I am working following the OAuth 2.0. The reasons why I choose to work with the OAuth 2.0 protocol is because OAuth 2.0 is the next evolution of OAuth protocol, a lot of online applications (as Google) considers OAuth 1.0 deprecated, and most of java libs build to work with OAuth, in this case we are using Apache Amber,  do not implement Oauth 1.0.

Now let's take a look at the OAuth protocol basics.

OAuth defines 4 roles, which take part in the protocol:
  • Resource owner: an entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
  • Resource server: 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 resource owner and with its authorisation. The term client does not imply any particular implementation characteristics (e.g. whether the application executes on a server, a desktop, or other devices).
  • Authorisation server: the server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorisation.

Let's take a look to OAuth work flow:

OAuth 2.0

The OAuth Client  register itself  in the Authorization Server, as result it will respond with a consumer key and with a shared secret.

The authorization code work flow diagram involves the following steps:
  1. Client obtains request_token: 
    a. The client requests authorization from the resource owner.
    b. The authorization request can be made directly to the resource owner (as shown), or preferably indirectly via the authorization server as an intermediary.
  2. Resource owner authorises request_token:
    c. The client receives an authorization grant which is a credential representing the resource owner's authorization, expressed using one of four grant types defined in this specification or using an extension grant type.
    d. The authorization grant type depends on the method used by the client to request authorization and the types supported by the authorization server.
  3. OAuth Client exchange its request token for access_token:
    e. The client requests an access token by authenticating with the authorization server and presenting the authorization grant.
    f. The authorization server authenticates the client and validates the authorization grant, and if valid issues an access token.
  4. OAuth Client uses its access_token to obtain protected resources:
    The client requests the protected resource from the resource server and authenticates by presenting the access token.
    The resource server validates the access token, and if valid, serves the request.

I've been working with Amber, I had problems trying to include the library in the project and meanwhile I was working the developers changed pretty much the library. The danger of working with a incubator project. Anyway, it's already working.
Sadly I could not find a good documentation about how to write a provider using this library, so if anyone in the community knows about it please share it in the comments, I would be really grateful.

Finally, my mentor, Carl Hall, helped me to understand some principles about OSGi than I had confused. Thanks! :)

I'll keep working in the OAuth Provider, just remember you than you could follow my work at github.
Any comments will be welcome, and any Amber tutorial too. :)

1 comment:

  1. Hi Mrs Hopper, feel free to write to for any questions.