Results 1 to 3 of 3

Thread: Oauth verifier required for authenticated request token processing in 1.0

  1. #1
    Join Date
    Jun 2011
    Posts
    1

    Default 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. #2
    Join Date
    May 2008
    Location
    Salt Lake City
    Posts
    167

    Default

    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.

  3. #3
    Join Date
    May 2012
    Posts
    1

    Exclamation 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 at 08:54 AM. Reason: add my version of code

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •