Hi Tien, On 15 Mar 2011, at 15:12, Hoang Minh Tien wrote:
> On 15/03/11 15:36, Scott Wilson wrote: >> On 15 Mar 2011, at 13:08, Hoang Minh Tien wrote: >> >>> >>> On 15/03/11 13:51, Scott Wilson wrote: >>>> Thanks Tien! >>>> >>>> On 15 Mar 2011, at 12:37, Hoang Minh Tien wrote: >>>> >>>>> Sorry, I have just update the figure to ascii code. >>>>> Here it is: >>>>> >>>>> Suppose that we stick to oAuth2 specification with the assumption Widget >>>>> and Wookie server are incapable of secretly keeping its credential the >>>>> reason is when the connection between the Shell and Wookie server is not >>>>> encrypted, the widget session id (which represents a widget instance, >>>>> generated from API key, shared data key, widget id, user id) is indeed >>>>> easy to capture, and once this happens any permanent parameters related >>>>> to this instance could be exposed through Wookie servlet API. For this >>>>> assumption, the most suitable oAuth2 profile for obtaining authorization >>>>> is the "Implicit authorization grant". >>>>> Another thing we should consider is that in the user point of view, the >>>>> Widget directly invokes the protected service, but in fact, the Widget >>>>> could only make request through the Wookie proxify mechanism. I.e., >>>>> Widget makes request with an URL proxified to Wookie server then Wookie >>>>> analyses the proxified URL and make request to the proper destination, >>>>> the result after that is forwarded back to Widget. So if we want to adapt >>>>> the Wookie server to be compliant with oAuthh2and reduce the work of >>>>> Widget developer, in such scenarios, we could consider Wookie Server as >>>>> an oAuth client, Widget is now similar to User-agent (in the sense that >>>>> it displays a form for resource owner to authenticate himself to oAuth >>>>> authorization server). The benefit is that we only put some simple >>>>> direction in config.xml of Widget to notice the Wookie server that oAuth2 >>>>> is enabled, and where is the oAuth authentication endpoint located. The >>>>> rest will be finished by Wookie server. >>>> OK, I think this makes sense. >>>> >>>> In the "normal" case, the application developer would obtain the consumer >>>> key from the target service, but in this case its actually the person who >>>> is managing the Wookie server instance who needs to obtain consumer keys >>>> for the widgets that need it - is this correct? >>>> >>>> Or is this step not needed any more in oAuth2? >>> I would say yes, the wookie server manage the client id (widget developer >>> may put this to config.xml). In this oAuth profile, the role of client_id >>> takes minimal effect, it is not to be used for validation of the client >>> identification. So I think it causes no problems if the value is exposed. >> Thanks Tien - I think when we last looked into OAuth this "implict grant" >> flow wasn't available - I've just done a bit of reading up on it and it does >> look like a very good fit for our scenario. >> >> Do you know if the Amber project will be producing libraries able to support >> "implicit grant"? Also, do you know if this type of oAuth flow is >> implemented by existing services (e.g. Twitter)? > For client side we could use Amber without any modification. But for the > server, I don't know either. oAuth 2-13 has just release from Feb16, so may > be it need times to update for servers. But it's great to hear your feedback. Well I think this is a good proposal and you should definitely go ahead. Does anyone else have any feedback? For Amber I suggest sending questions to the amber-dev list. > For the storage of "access token" I'd like to store it as temporary session > variable rather than permanently in wookie db. I don't know whether is is > possible because each time refreshing the page which contains widget, my > Tomcat generate a new session id for widget. How do you think ? I have a > mal-configured Tomcat server ? I haven't come across this myself, its possible there is an issue with your Tomcat configuration. Why is it important not to save access tokens between sessions? Is this a requirment of the oAuth profile? >>>>> >>>>> >>>>> Step 1: Wookie has not yet obtained the access token for this widget >>>>> instance, and receive a request to invoke the protected service from >>>>> Widget. >>>>> Step 2.1: Wookie follows the direction in config.xml to see where is the >>>>> authorization end point, send some basic information to authorization >>>>> endpoint (client_id, redirect URL) >>>>> Step 2.2: Wookie redirects the widget to authentication screen, wait for >>>>> user authentication >>>>> Step 3: User key in the credentials (username/passwords) and grant >>>>> permission. >>>>> Step 4: If user successfully enter his credential and accept granting the >>>>> authorization, oAuth authorization server will return an "access token" >>>>> Step 5: Wookie server will use this token to invoke protected service. >>>>> When the "access token" is ready, for the next requests from widgets, >>>>> wookie server directly forward the request with "access token" issued in >>>>> step 5. >>>>> >>>>> On 15/03/11 13:07, Scott Wilson wrote: >>>>>> Hi Tien, >>>>>> >>>>>> I don't think attachments can be used on these lists - can you paste it >>>>>> inline or upload it somewhere and include a link? >>>>>> >>>>>> S >>>>>> >>>>>> On 15 Mar 2011, at 10:58, Hoang Minh Tien wrote: >>>>>> >>>>>>> Hi guys, >>>>>>> I made some general description of workflow for an oAuth enabled Wookie >>>>>>> server in the attachment. Please tell me how do you think about that >>>>>>> and please share if you have other idea, all comments are welcome. >>>>>>> Thanks. >>>>>>> Tien. >> >
