I'm just starting to use the Spring OAuth module and I'm a bit confused about its processing of an authorized request token in OAuth spec 1.0 (not 1.0a). I'm writing a client which is attempting to gain an access token through the standard OAuth 1.0 workflow, and I believe that I'm seeing some incorrect behavior regarding processing of an authorized request token handed back by the service provider.
In my webapp's workflow, the OAuth module is able to successfully gain an unauthorized request token from the service provider, redirect the client to the service provider's authorization page, and the service provider then redirects the client back to my webapp with the authorized request token once the user has authorized it. Since the service provider in this case is an OAuth 1.0 service provider, the authorized request token does NOT come back from the service provider with a verifier.
The strange thing that I see in the M3 code is that when the OAuth module processes the inbound authorized request token, it looks for a verifier without checking first to see if it's configured for 1.0 or 1.0a. When it doesn't find a verifier attached to the request (again, because I'm talking to a OAuth 1.0 service provider), it just tosses away the valid, authorized request token and starts the OAuth workflow all over again.
I'm wondering if there should be a check, upon receiving a request token which has been authorized, if the client is configured for OAuth 1.0 vs 1.0a, and only check for the presence of a verifier if 1.0a is selected.
I should note that it's possible that I've missed some key part of the protocol somewhere, but this is my understanding from reading the 1.0 spec here.
Has any one else experienced this problem, or can possibly confirm (or deny) the existence of this issue?


Reply With Quote