Examples of OAuth with multiple authorization tokens?

Is there an example of an OAuth implementation or profile which uses multiple authorization tokens in one interaction? C开发者_Python百科an this be done with vanilla OAuth (as opposed to an extension)? Is there any discussion on the reasons for or against using multiple tokens in one request?

OAuth WRAP uses two tokens, but only one is an authorization token; the other is a request token which is used to obtain a new authorization token. What is the reasoning behind this? Does this bake sessioning into a single authorization token simply to make token passing more straightforward? Does anyone recommend building OAuth authorization tokens in this way across multiple interactions?

---

A "protected resource request" (i.e. a request to retrieve some resource which requires you to authenticate using OAuth) in standard OAuth carries only one OAuth token. The consumer key is also sent. The secrets corresponding to each of these tokens are used together to generate the signature.

WRAP also has the concept of an access token but it introduces the concept of a refresh token which is not included in a protected resource request but is instead sent in a direct request from client to service provider when the client's access token has expired and it needs to obtain a new one.

WRAP tokens, unlike OAuth tokens, do not have an associated secret but is instead used more like a temporary session identifier. Since this token may be exposed in a browser cookie or other browser state, WRAP allows for that token to be short-lived, allowing it to be discarded when the user signs out or after some short period of inactivity. The refresh token is known only to the client and service provider and is thus longer-lived.

A refresh token is not necessary in OAuth because the Token Secret serves as the secret known only to the client and service provider.

Both protocols have two values for the client to keep track of, one of which is more private than the other, but WRAP uses the more private token in a different way such that implementers do not need to generate and verify signatures.