Hey Andrew -
Two-legged OAuth is a very confusing term. I've tried to stop using it,
because it means so many different things to different people. I'm not 100%
sure what your use case is...
The current OAuth2 draft handles traditional client-server authentication
with the client credentials flow:
client_id + client_secret => access_token
There is another flow that I think got dropped from the draft(?) but that
various people have implemented:
client_assertion => access_token
That flow has better security than the client_secret flow, since it can use
public key authentication instead of password authentication.
But I wouldn't recommend that desktop side-bar gadgets (your use case) use
either of those flows, since as you point out they can't keep secrets.
We're handling gadgets using OAuth2 as small-view web applications. They
use the user-agent flow with auto-approval of tokens after the user's first
consent ("immediate mode"). For example:
- iframe redirects to google's authentication service
- google's authentication service checks that the callback URL of the iframe
belongs to an app the user trusts
- google redirects back to iframe with a short-lived (one hour) access token
- iframe makes RPCs back to google through various channels. All of the
RPCs are authenticated with the access token
Does that sound like what you're getting at?
Cheers,
Brian
On Sat, Apr 30, 2011 at 8:50 PM, Andrew Arnott <andrewarn...@gmail.com>wrote:
> Does this
> doc<http://oauth.googlecode.com/svn/spec/ext/consumer_request/1.0/drafts/2/spec.html>accurately
> describe what the community generally refers to as "two-legged
> OAuth"? If so, I have a couple questions...
>
> What about this is "*two* legged"? I count zero legs. The consumer
> already has a key and secret, and uses them to access resources. Not a
> single one of the 3 legs in standard OAuth's "unauthorized request token,
> authorize, exchange for access token" flow are present in the above linked
> spec by my reading of it.
>
> I expected two-legged OAuth to be more like this:
>
> 1. The client presumably already has a consumer key, but perhaps no
> secret since these clients can rarely keep secrets. I'm imagining clients
> that are desktop sidebar gadgets, perhaps.
> 2. Upon first run, this app performs these two legs:
> 1. Obtains a request token using the standard OAuth 1.0 flow. This
> would traditionally be an unauthorized request token. But in 2-legged
> OAuth
> this request token is implicitly auto-authorized, for access to a new,
> empty
> account on the service provider.
> 2. Exchanges the request token for an access token, again using the
> standard OAuth 1.0 flow for that step.
> 3. At this point, the client has a consumer key, perhaps a consumer
> secret, and an access token and token secret. The token represents an
> empty
> account, but may be filled and later queried by that client. The fact that
> the client has no consumer secret is of little consequence because the
> access token secret is unique for this particularly installation of the
> client and therefore the data is protected.
>
> So... which one is right? And does the "wrong" one have any validity?
>
> Thanks.
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
