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
