Enterprise Integration Zone is brought to you in partnership with:

I am currently working as a Software Architect and a Senior Manager at WSO2. I have spoken in numerous conferences - OSCON 2009, ApacheCon 2009, WSO2Con 2010, WSO2 SOA Workshops and WSO2 Security Workshops. I am a graduate from University of Moratuwa, Sri Lanka and in 2008 I completed my Masters specialized in software architecture from the same University. I also gained professional qualifications in BCS and ACS as well as certifications in SCDJWS, SCJP, SCBCD, SCWCD, MCSD, OCA, and CCNA. Prabath is a DZone MVB and is not an employee of DZone and has posted 21 posts at DZone. You can read more from them at their website. View Full User Profile

What OAuth Lacks: Resource Owner Initiated OAuth Delegation

  • submit to reddit
Irrespective of all the criticism against OAuth 2.0 - it has produced a very powerful, highly extensible authorization framework.

The use cases covered in the spec are not imaginary - rather very realistic.

At WSO2 we have integrated OAuth 2.0 support in to WSO2 Identity Server and WSO2 API Manager. Currently we do support all four grant types defined in the core specification. Also - we have very strong customer use cases for SAML2 grant types as well - which we have already started implementing.

If you look at the core specification - there are two key roles involved.

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.

Client : An application making protected resource requests on behalf of the resource owner 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).

Now if you look at the complete OAuth flow - you will notice that - all are initiated by the Client. This has ignored the use cases where the Resource Owner has to initiate the flow. Let me give a more concrete example.

I am a user of an online photo sharing site. There can be multiple Clients like Facebook applications, Twitter applications registered with it. Now I want to pick some client applications from the list and give them the access to my photos under different scopes. Validation of the trust/legitimacy of the registered applications can be carried out in other means.

That is just an example from social networking point of view. But there are more concrete enterprise use cases as well.

Let's take an access delegation use case.

I am an employee of Foo.com. I'll be going on vacation for two weeks - now I want to delegate some of my access rights to Peter only for that time. Conceptually OAuth fits nicely here. But - this is a use case which is initiated by the Resource Owner - which is not addressed in the OAuth specification.
Published at DZone with permission of Prabath Siriwardena, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)