RequestTokens only able to generate a single AccessToken

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Generate a RequestToken and authorize it
2. Perform the steps to generate an AccessToken via the RequestToken
3. Attempt to generate a second AccessToken from the same RequestToken

What is the expected output? What do you see instead?
As I understand it, a consumer is meant to be able to generate an arbitrary
number of AccessTokens with the same RequestToken. The process to authorize
a RequestToken involves manual user interaction, which we only want once.

It turns out that the RequestToken is marked as "Used" after a single
AccessToken is generated from it. This is in the
AccessTokenHandler.IssueAccessToken method.

It might be useful if there was some mechanism to allow a single associated
AccessToken at a time, but I don't think that is what's happening here.

What version of the product are you using? On what operating system?
0.7.1.0

Please provide any additional information below.
It looks like the sample application "EchoServiceProvider" faced the same
issue and worked around it in the same fashion that I've taken. So this may
have been intentional for some reason...

Original issue reported on code.google.com by Samuel.D...@gmail.com on 5 Mar 2010 at 6:10

[GoogleCodeExporter]

Hi Samuel,

This behaviour is expected and required by the OAuth spec. Section 6.3.2 of the 
OAuth Core 1.0a spec 
(http://oauth.net/core/1.0a/#auth_step3) states that:

---

The Service Provider MUST ensure that:

* The request signature has been successfully verified.
* _The Request Token has never been exchanged for an Access Token._
* The Request Token matches the Consumer Key.
* The verification code received from the Consumer has been successfully 
verified.

---

A request token is only allowed to be used once to get an access token. 
However, an *access token can* be used an arbitrary 
number of times. While individual service providers may limit the number of 
times an access token can be used or the time 
period for which it is valid, there is nothing in the spec to require this.

I hope this has cleared this up for you. Let me know if you have further 
questions.

Cheers,

Bruce Boughton

Original comment by bruceboughton on 7 Mar 2010 at 5:11

• Changed state: Invalid