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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Andrew Arnott Sent: Saturday, April 30, 2011 8:50 PM To: OAuth WG (oauth@ietf.org) 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. 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: * 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
