Thanks for this great write-up of how oAuth works, Sunand. I'm cc'ing dev for this, and copying it into ISIS-736 and ISIS-739 as a comment.
https://issues.apache.org/jira/browse/ISIS-736 https://issues.apache.org/jira/browse/ISIS-739 On 22 March 2014 05:16, sunand p <sunandonl...@gmail.com> wrote: > Hi Dan, > > Thanks for the reply, I am following user mailing list. I read through the > dev mailing list, its interesting. It will be awesome if oAuth gets > delivered as part of this usecase. > > 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) > > 1. https://accounts.google.com/o/oauth2/auth -- This is the > authorizaiton URL provided by google > 2. https://accounts.google.com/o/oauth2/token -- This is the token > generation URL provided by google > 3. 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, > > 1. 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. > 2. Once done it will prompt for App Access with proper permissions > like you see in facebook with "Allow" and "Deny" buttons. > 3. Once you say Allow, it is redirected to the callback URL with a > code. > 4. Using the code, client credentials and token url we will get a > Refresh Token as well as an Access Token. > 5. 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. > 6. 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. > > HTH > > -Sunand > > > > On Thu, Mar 20, 2014 at 3:30 PM, Dan Haywood <d...@haywood-associates.co.uk > > wrote: > >> Sunand, >> >> Appreciate that no-one answered this posting of yours. >> >> Don't know if you've been following the Isis dev mailing list also, but >> there's a thread [1] there discussing integrating Isis with context.io[2], >> which also requires solving the oauth integration. >> >> I'm still not clear (myself) on how this would work, but hopeful that >> it's doable one way or the other... >> >> Dan >> >> [1] http://markmail.org/thread/4ilfxcc2aoxy7nfw >> [2] http://context.io >> >> >> >> On 18 February 2014 18:07, sunand p <sunandonl...@gmail.com> wrote: >> >>> Hi All, >>> >>> I already have a thread running StackOverflow >>> >>> http://stackoverflow.com/questions/21547063/apache-isis-extending-rest-service >>> , >>> As per Dan's suggestion I am raising this topic in users list. Please >>> Read >>> through and let me know your suggestions, for a quick and short >>> explanation >>> on what i want to do, here is the gist >>> >>> "Let me explain with an example, ga-dev-tools.appspot.com/explorer once >>> you >>> open this link you will see a query explorer for Google Analytics API. In >>> order to execute the Query first we need to Authorize Access which is a >>> button on top right, once clicked it opens an external window with an URL >>> (oAuth flow happens). Once we get token then we can fire a query and >>> fetch >>> the result. I want to build a web app similarly for other providers like >>> LinkedIn, Salesforce, Facebook. All i need to do is store the connection >>> properties make an oAuth call fetch the token and access the resources. >>> Do you think Isis doesn't fit the above requirement? I feel that an >>> External Link feature of Apache Wicket should suffice the requirement. >>> Also >>> redirecting it back to the original page. For fetching http response i >>> can >>> use apache http client and consume the entity." >>> >>> - Sunand >>> >> >> >
