What OAuth Lacks: Resource Owner Initiated OAuth Delegation
DZone's Guide to
What OAuth Lacks: Resource Owner Initiated OAuth Delegation
Join the DZone community and get the full member experience.
Join For FreeSnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.
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.
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.
With SnapLogic’s integration platform you can save millions of dollars, increase integrator productivity by 5X, and reduce integration time to value by 90%. Sign up for our risk-free 30-day trial!
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 }}