[Opensim-dev] OAuth as authentication and authorisation (capability) specification

[Christian Scholz]

Hi!

Melvin Carvalho schrieb:
> On Tue, Apr 28, 2009 at 2:04 PM, Tommi Laukkanen
> <tommi.s.e.laukkanen at gmail.com> wrote:
>> Ouch, any chance of standard extension to support rich clients :)
> 
> Christian is likely to know more, but hopefully the larger providers
> will work on providing something like this.

So just to recap how it works in the website case.

You have the following entities:

- The OpenID Provider (OP) which can verify that an OpenID indeed 
belongs to a user by means of logging the user in to prove it. Login can 
be done by many means, usually username/pw but also InformationCards or 
an SSL client cert.
- The Relying Party (RP) is a website which wanst to log a user in.
- The user who wants to login to an RP

And the process is roughly:

1. User enters his OpenID (URI) at the RP
2. RP performs service discovery on that URI to check if an OpenID 
server endpoint can be found
3. RP contacts the endpoint at the OP and initiates a session
4. RP redirects user to the OP to verify this OpenID
5. OP asks the user to login if he isn't already (probably via a 
cookie). User logs in
6. OP asks the user if it's OK to tell the RP that you own that OpenID. 
User confirms
7. OP redirects the user back to the RP
8. RP checks back with the OP if the user was verified.
9. OP says yes and RP is happy

So in the website case the RP is some web site, e.g. some social network.

Now because the web browser is only used to show pages it needs to 
redirect to the OP so that the user can login. It will probably hold 
some cookie from the OP to keep it's login state.
It also needs to show the URL of the OP to the user so the user can be 
sure it's the right site and does not enter username/password on some 
phishing site.

In the virtual worlds case the RP is probably some region/simulator 
which wants to know who is trying to login.

Now I am not into all the security details of OpenID and what attacks 
are possible (certainly phishing is but migth be helped by 
InformationCards or SSL certs to login) but maybe some extension for 
rich clients can be thought of.

I assume that you always have to trust your client anyway, be it a web 
browser or some virtual worlds client. So a possible extension could 
maybe work as follows:

1. User enters OpenID and region URI in VW client
2. VW client checks what login methods are available at the region (e.g. 
via XRD/LRDD based service discovery). It finds OpenID
3. The VW client posts the OpenID to the region's OpenID service (this 
needs to be defined)
4. The region performs OpenID service discovery (also called YADIS) and 
find the OP server endpoint as well as our new extension for logging the 
user in. This results in a URI at the OP.
5. region establishes an OpenID session with the OP
6. If the extension in 4 is found then it returns the request from the 
VW client and informs it to ask for username and password and gives that 
URI for the extension.
7. The VW client shows the OP URI (so the user knows where he logs in) 
and asks for username/password
8. The VW client sends this information to that OP URI and receives some 
key which it sends back to the region in turn (maybe an OK would be 
sufficient so the client knows that the login was successful)
9. The region then checks back if the OpenID was valid and the user if 
logged in.

Now this means that

- the region never sees any username/password
- the OP can only support username/password logins but maybe there could 
be several extensions to choose from
- the step where the user confirms that the information is sent back to 
the RP is missing but maybe that's not really needed here.
- the user needs to login for each new region again as there is no means 
of maintaining a session with the OP right now.

Now if the extension is not found (e.g. a normal OpenID provider as of 
today) then the client could simply act as a web browser and will show a 
regions login screen where the user can enter an OpenID. The redirect 
would be as in the standard specs and after that the region might use 
some redirect with a protocol handler (e.g. opensim://) to initiate the 
sim connection. The URI of that would probably need some UUID/key so 
that the region can confirm that this redirect is in fact coming from 
the user which just logged in.

Ok, these are my late evening thoughts.

As for the web needing some more intelligent client, maybe that's right 
but then again we have to deal with it as it's now ;-)

And another question might be if it would be easier with an OAuth based 
solution and I will give this some thought the next days. Probably it is 
because the redirect is only an option in there while it's mandatory in 
the OpenID spec. And the above idea might also be worthwhile to discuss 
on the OpenID list so maybe I will do that once I thought about this a 
bit more.


-- Christian

-- 
COM.lounge GmbH
http://comlounge.net
Hanbrucher Strasse 33, 52064 Aachen
Amtsgericht Aachen HRB 15170
Geschäftsführer: Dr. Ben Scheffler, Christian Scholz

email: info at comlounge.net
fon: +49-241-4007300
fax: +49-241-97900850

personal email: cs at comlounge.net
personal blog: http://mrtopf.de/blog
personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net