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.
+---------------++-----------------+
| 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.
