Re: [mmox] OGP scalability concerns

[Christian Scholz <[e-mail]>]

Hi!


Jon Watte wrote:
> Christian Scholz wrote:
>> The redirect setup is only one example of obtaining the OAuth token.
>> You can do it whatever way you want to (the new version of the spec
>> also makes that clearer as it starts with just the way you actually do
>> authorized requests and only explains in the second part the redirect
>> mechanism).
>>
> 
> When I register as a service provider for an OAuth service, I have to
> register a callback URL. That seems pretty hard-coded into the actual
> implementation to me. That service provider won't work with a service
> that doesn't have a user-visible callbacl URL.
> 
>> But if you look at e.g. iMovie and how it uploads movies to YouTube
>> you have an example of how a desktop app can do it (although it's not
>> using OAuth I think but probably Google AuthSub but it's basically the
>> same).
>>
> 
> The problem is not the desktop app not being reachable; the problem is
> the service requesting authentication not being reachable from the
> authentication provider.

So lets look at the spec as it is right now:
http://tools.ietf.org/internet-drafts/draft-hammer-oauth-02.txt

And maybe we should use the same terminology because I might simply be
confused ;-)

So we have:

- a protected resource. This resides on a server and a client wants to
access it on behalf of the server. Could e.g. be a photo

- a client which wants to make an authenticated request to access the
protected ressource. For instance it could be a desktop app as iMovie or
it could be some server somewhere which wants to access e.g. this photo
(or a simulator which wants to access avatar data)

- a resource owner which is basically the user who owns that photo or
avatar.

(in the old spec there was a consumer which is now the client and a
service provider which is now the server storing the protected resource).


The main part of the new version of the specification is about how a
client is supposed to do an authenticated request to obtain the
protected resource. Basically it's using a token and client credentials
to sign the request. The client credential identify the client and the
token identify the resource owner (which need to have given consent to
access it beforehand).

If the signature is valid then access is granted.

Section 4 of the specification defines how a token can be obtained by
the client. But it also says that this is only one possible method. And
this method actually involves the callback URI.

If you now look in section 4.2 you see an OPTIONAL in the description of
oauth_callback. It says:

   oauth_callback
         OPTIONAL.  The client MAY specify an absolute URI for the
         server to redirect the resource owner back to the client when
         authorization has been obtained or denied.

If no callback URI is defined (as it would be definitely true for
desktop apps which can also act as a client) then the server simply
informs the user that this step is finished and the next action needs to
be taken in the client. Usually the user then switches back to the
client desktop app or maybe web page and clicks "Continue".

In an implementation with a web server as a client this might look like
follows:

1. The client web server obtains a temporary token
2. The client web server opens a popup for the resource owner with the
authorization URL of the server storing the protected resource
3. The resource owner (user) eventually logs into the server and gives
consent for the client to access that data (in that popup)
4. The server then tells the resource owner to continue on the client
and shows a "Close window" button.
5. The user clicks that and clicks "Continue" in the main web page of
the client
6. The client then exchanges the temporary token with an access token
behind the scenes.

Here no callback URI is used but usability is maybe also a bit limited
due to that.

Now in the case of virtual worlds we probably have one more party: The
VW client. So we have the following parties involved:

- VW client: The desktop app for using the VW
- VW server: The server the VW client connects to in the first place. It
also acts as a client towards other servers hosting protected resources.
- other servers: Those servers hosting e.g. the profile of a user or
textures or 3D objects

And here it becomes more complicated and there is maybe no solution yet
to it. So this part might be what needs thinking in terms of:

- How would authorization/authentication work at all in such a
distributed environment?
- How can this be implemented with e.g. OAuth (or other means)?

I hope at least the first part of my reply answers your question
regarding callback URIs. Of course another possibility would be to use a
non-web based mechanism for the client to get hold of the access token.
This might be defined in an OAuth Extension.

-- Christian


-- 
Christian Scholz                          Homepage: http://comlounge.net
COM.lounge GmbH                              blog: http://mrtopf.de/blog
Hanbrucher Str. 33                                       Skype: HerrTopf
52064 Aachen                             Video Blog: http://comlounge.tv
Tel: [phone]                           E-Mail [e-mail]
Fax: [phone]                               IRC: MrTopf, Tao_T

neuer Podcast: Der OpenWeb-Podcast (http://openweb-podcast.de)
new podcast: Data Without Borders (http://datawithoutborders.net)