OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Martin Atkins wrote:
> There's also the need to have something to point at as what the user 
> trusted, so that other applications can't piggy-back off the trust of a 
> popular app.
>
>   
Hi Martin,

The OAuth access token is the credential that is issued to the instance 
of the application that was authorized. Although the SP might not be 
able to identify the application, the Access Token can be used to 
identify the instance of whatever app it was that was authorized by the 
user.

> It doesn't matter so much if the former is compromised, but it is very 
> important that the second isn't compromised.
>   
All applications are expected to secure store their Access Token Secret, 
which was issued along with the AT.

> It seems like there needs to be two tokens here. One is provisioned by 
> going through some registration flow on the SP site,
This is the OAuth Consumer Key and Consumer Secret. The CK identifies 
the application, and the CS is used to sign requests on behalf of the 
CK. Unfortunately, the CS can be easily compromised for all non-server 
based applications.

>  and the other is 
> provisioned automatically *by each installation* of a desktop/mobile 
> app. The latter is known only to that installation and so a user trusts 
> only their installation of the app, not an installation of the same app 
> on someone else's system.
>
>   
Yup, this is the OAuth Access Token and Access Token Secret.


> I guess the flow I'm imagining is as follows:
>
> * App author applies for an application identifier through web forms as 
> normal.
> * App author creates a desktop app that is distributed with that 
> application identifier embedded in it.
> * On install or first run, the app makes a back-channel request to an 
> endpoint at the SP to get a consumer key that's attached to the 
> application identifier but known only to that install.
> * Henceforth, the app does OAuth as normal using the single-instance 
> consumer key.
>
>   
I think the existing OAuth dance is pretty much equivalent (although 
different) than what you describe.

Allen