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:

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. :)

Oauth integration: First month report

Summer is on, so it's code time. Hooray!

Beginnings are always harder, but the first development month have passed (as my finals) and I would like to speak about what I've been doing so the Sakai community will be updated properly. First of all, I must thank my mentor, Carl Hall for his work.

Now, let's talk about the project. Let's begin with the basic, this is the Oauth definition that we could find in the Wikipedia:

OAuth is an open standard for authorization. It allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically supplying username and password tokens instead. Each token grants access to a specific site (e.g., a video editing site) for specific resources (e.g., just videos from a specific album) and for a defined duration (e.g., the next 2 hours). This allows a user to grant a third party site access to their information stored with another service provider, without sharing their access permissions or the full extent of their data.

We can easily realize how useful it is for Sakai Nakamura to have an Oauth provider. It will allow third part applications, as native mobile apps, access to private resources to the users, useful isn't? Moreover, the community has already identify this need here [0]

 This first month I've been working basically in setting up the development environment, and learning about Oauth protocol. I was planning to write a tutorial with my notes but this tutorial [1], it's really useful. Anyway, if the spanish-speaking community will find it useful a translation of it, leave a comment and I will write it happily. Also, I fork Nakamura repository and I began to write the skeleton of the Oauth Client and Oauth Server (right now it's just an hello world), you can follow the development here [2].

I hope you are interested about the project, I would like to hear some feedback. And if you have anything to ask or suggest me, please do not hesitate.

By the way, happy Turing's day :)

[ 0] https://confluence.sakaiproject.org/display/KERNDOC/KERN-807+Add+support+to+the+proxy+server+for+3th+party+OAuth+applications
 [1] https://confluence.sakaiproject.org/display/KERNDOC/Nakamura+Boot+Camp
 [2] https://github.com/mshopper/nakamura