Hey Matt, It's a question of who has to have what secrets. In principle you're right that you could get by with the consumer having a single shared secret with the provider, and just passing around request token and the access token without using any corresponding secret, but there is some operational rational for separate tokens:
Namely that they can be used to create separate roles for different parts of the OAuth process: Notice that the consumer token, the request token, and the access token are used in three different transactions: 1. Requesting a request token 2. Requesting an access token 3. Requesting the protected resource If you used the same secret for all these requests, then the three entities making the requests would have to all have the same secret. And there are cases where you want separate entities to handle different parts, for example, a private authorization server to handle 1, a customer-facing server that handles 2 (and the user part of delegation procedure), with some other background server actually accessing the protected resources. Having a separate secret for each request makes it easier to implement such a division of labor: 1. The authorization server gets request token, passes request token (and secret) to customer-facing server 2. Customer-facing server gets request token authorized, uses it to get an access token (and secret), passes access token and secret to background server. 3. Background server uses access token and secret to access resources Through this whole thing, only the authorization server has to have the long-lived consumer secret (which makes it easier to protect), but all of the requests are still properly authenticated. Hope this helps, --Richard On Tue, Jan 26, 2010 at 4:00 PM, Matt <[email protected]> wrote: > I've been reading the OAuth 1.0a spec, specifically at the example/ > walk-through provided starting at http://oauth.net/core/1.0a/#rfc.section.A.1 > > I don't quite understand why so many secret tokens are exchanged > during the "conversation" in a HMAC-SHA1 signed situation. > Specifically: > > 1) The consumer already has their public/secret token, which, in > theory, should be sufficient for signing *any* request made against > the provider. > 2) In Appendix A.2. the consumer asks for a request token. The > provider responds with an oauth_token and a oauth_token_secret. > 3) The oauth_token_secret provided in A.2 is then used in the query > string when the consumer asks for the access token (A.4). What is the > purpose of the oauth_secret_token here? > 4) The access-token request returns a response body that contains > another oauth_token and oauth_token_secret. This 3rd secret token is > then used in combination with the pre-existing secret consumer-token > to access a resource. > > Why do 3 secret tokens need to participate in this conversation? Why > is the secret token for the consumer not enough? What is that 2nd > secret token used for (the one provided as a response when asking for > the original request-token), and why is the 3rd combined with the > consumers secret to sign resource-requests (instead of just the > consumer secret)? > > regards, > Matt > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/oauth?hl=en. > > -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
