[
https://issues.apache.org/jira/browse/ISIS-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944001#comment-13944001
]
Dan Haywood commented on ISIS-739:
----------------------------------
Sunand P wrote the following useful stuff about oAuth on the users list:
oAuth2 please have a look at libraries like oauth-jersey-client or Apache OLTU
or Spring oAuth and yes Scribe is also good option. Mainly oAuth is used in
Integration Projects (connecting 2 different systems). When it comes the oAuth
client, its very simple you just need to follow the handshake process
implemented by respective oAuth Serivice providers in above case context.io. In
general they follow the spec, http://tools.ietf.org/html/rfc6749
To Save the trouble here is a quick gist on oAuth 2 client side explanation.
(please read the documentation for detailed explanation below is the
explanation based on my work done on oAuth)
1) oAuth2 is hosted service provided by a 3rd party for authentication through
which once authenticated one can access the resources.
2) So one has to register for the service. All it requires is what is the
external app which is trying to connect to its system and its callback url
(this url which is hosted on the user side) is used in the authentication
process.
3) Once registered, there is an App Id generated for identifying the
application as such, then you will be given an Client ID and Client Secret.
4) In general there will be 3 urls for oAuth flow, (lets take google as an
example, if required i can give you salesforce example as well)
https://accounts.google.com/o/oauth2/auth -- This is the authorizaiton URL
provided by google
https://accounts.google.com/o/oauth2/token -- This is the token generation URL
provided by google
http://localhost:9070/api/ga/oauthcallback -- This is the oauth call back URL
hosted on the users end.
(There are other options which can be set during the flow which i am not
getting in to those details)
5) Handshake happens like this,
Make an Authorize request with client credentials, this will go and check
whether our external app is up and running with the help of callback url.
Once done it will prompt for App Access with proper permissions like you see in
facebook with "Allow" and "Deny" buttons.
Once you say Allow, it is redirected to the callback URL with a code.
Using the code, client credentials and token url we will get a Refresh Token as
well as an Access Token.
Refresh token is equivalent to your password and access token is a short lived
resource using which we can access the external system protected resource.
>From here on you just require Refresh Token to generate access token to
>establish API to API communication from back-end. So any scheduling jobs or
>background jobs do not require an end user interaction.
All in all this is the story of Client Side of oAuth. Sorry for this huge
email, i thought i could help :)
Building a client as such should be outside of WicketViewer on top of
RestfulViewer. Or we need to write a custom component in wicket or servlet. I
couldn't get much time in starting the project due to other work deliverables.
> For GSOC, to develop an oAuth integration
> -----------------------------------------
>
> Key: ISIS-739
> URL: https://issues.apache.org/jira/browse/ISIS-739
> Project: Isis
> Issue Type: Wish
> Reporter: Dan Haywood
> Priority: Minor
> Labels: gsoc, gsoc2014
>
> probably not a full summer's work though (even though I'm not exactly sure
> what an oAuth integration actually is)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
