Subject: [OAUTH-WG] OAuth 1.0 2-legged scenario

From: Andrew Arnott <[email-masked]>
Date: Sat, 30 Apr 2011 20:50:27 -0700

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 30 Apr 2011 22:38:08 -0700

The term 'two-legged' really means traditional client-server communication, where the OAuth 1.0 signature flow is used for authenticating the client. There are a few flavors of this, some using just the client credentials and others using an access token as well.

The original idea was that if the client already has a set of credentials established with the server, using OAuth is better than HTTP Basic, even if no resource owner is involved.

OAuth 2.0 does not cover this use case, as all token authentication is defined elsewhere. The MAC draft is specifically designed to address it.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Arnott
Sent: Saturday, April 30, 2011 8:50 PM
To: OAuth WG ([email-masked])
Subject: [OAUTH-WG] OAuth 1.0 2-legged scenario

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.

 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:

    *   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.
    *   Exchanges the request token for an access token, again using the standard OAuth 1.0 flow for that step.

 1.  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