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.
What OAuth Lacks: Resource Owner Initiated OAuth Delegation
DZone's Guide to
What OAuth Lacks: Resource Owner Initiated OAuth Delegation
by
Join the DZone community and get the full member experience.
Join For FreeMigrating from On-Prem to Cloud Middleware? Here’s what Aberdeen Group says leading companies should be considering. Brought to you in partnershp with Liaison Technologies.
Is iPaaS solving the right problems? Not knowing the fundamental difference between iPaaS and iPaaS+ could cost you down the road. Brought to you in partnership with Liaison Technologies.
Like This Article? Read More From DZone
Topics:
Published at DZone with permission of Prabath Siriwardena, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}