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