Announcement Announcement Module
Collapse
No announcement yet.
Oauth verifier required for authenticated request token processing in 1.0 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Oauth verifier required for authenticated request token processing in 1.0

    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?

  • #2
    Might be a bug. I've opened an issue for you:

    https://jira.springsource.org/browse/SECOAUTH-74

    We'll check it out before M4 gets released.

    Comment


    • #3
      Strange patch

      Alter https://jira.springsource.org/secure...coauth74.patch this patch, we have next code:

      Code:
      // 
      if (token == null || (!token.isAccessToken() && (!resourceThatNeedsAuthorization.isUse10a() || verifier == null))) {
          // get and authorize request token -- block-A
      } else if(!token.isAccessToken()) {
         // get access token -- block-B
      }
      If oauth-resource has property use10a=false, any callback request from service provider will be catched by ("block-A") and access token code "block-B" will never be executed. Or i'm wrong?


      p.s. my version of this condition:
      Code:
      if(token == null || (!token.isAccessToken() && resourceThatNeedsAuthorization.isUse10a() && verifier == null)))
      Last edited by fogone; May 23rd, 2012, 09:54 AM. Reason: add my version of code

      Comment

      Working...
      X