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? > > +---------------++-----------------+ > > | Widget|(5)| oAuth protected | > > (3)| container|+--------->| service| > > o --+---------+|||| > > /I\||+(1) +-----+----++-----------------+ > > / \|+---v---+-+--------->| Wookie| > > ||Widget | || server|(4) > > |+-------+<+----------|+-----------+ > > ||(2.2) +-----+----+| > > +---------------+|| > > |+-----v-----------+ > > |(2.1)|oAuth| > > +--------->|authorization| > > |server| > > +-----------------+ > > > 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. >>
