[OAUTH-WG] OAuth 1.0 2-legged scenario

Andrew Arnott <andrewarnott@gmail.com> Sun, 01 May 2011 03:50 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=DjWGJ/jcwXxq40aA39SjJnEsjpB1rAZrAEU6sWTK2cm9pghLxrXCuhe5AknU2Un42f waqdOjDQFt+bwK+TY7fijEBEHkHuYGGetycTZEspsT+ewMNP/XqUXTybVbt/JTRu1sSn qEW7SxzOKQl9JTyB/Tps/Qn526KY/KUWGtVEM=
MIME-Version: 1.0
From: Andrew Arnott <andrewarnott@gmail.com>
Date: Sat, 30 Apr 2011 20:50:27 -0700
Message-ID: <BANLkTini_fuL4EjLOm_W=J=C4N4i1q+kYg@mail.gmail.com>
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0016360e3f5ceb4a8d04a22ecfb8"
Subject: [OAUTH-WG] OAuth 1.0 2-legged scenario
Precedence: list

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-WG] OAuth 1.0 2-legged scenario Andrew Arnott
Re: [OAUTH-WG] OAuth 1.0 2-legged scenario Eran Hammer-Lahav
Re: [OAUTH-WG] OAuth 1.0 2-legged scenario Brian Eaton