Announcement Announcement Module
Collapse
No announcement yet.
Specifying which urls to apply Spring OAuth 2 provider to Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    HI Dave, can see that you had a go at fixing SECOAUTH-122, but I'm afraid we're still experiencing the 'client secret mismatch' error, but the circumstances are under which it fails are hard to pinpoint.

    Sparklr2 and Tonr2 now appear to work using secrets, which is great. However, it seems that there are authentication issues with other clients. Before implementing the changes on our own app, we attempted to authenticate with Sparklr using a PHP Oauth2 client, with the same set of credentials as tonr. We have used this PHP client before with other oauth2 providers and not encountered this issue, so at present we are trying to establish where the possible cause could stem from. Authorization works fine, its authentication with secrets thats still the issue.

    Here is the http exchange captured by wireshark, after authorization.

    This is the OAuth clients authentication to our application
    Code:
    POST /hubbub/oauth/authorize HTTP/1.1
    Host: aesop:8080
    Accept: */*
    Content-Length: 166
    Content-Type: application/x-www-form-urlencoded
    
    grant_type=authorization_code&type=web_server&client_id=client&client_secret=secret&redirect_uri=http%3A%2F%2Fbgallagher%2Foauth2%2Fhubbub2.php&code=8et981&scope=read
    And this is our applications response
    Code:
    HTTP/1.1 401 Unauthorized
    Server: Apache-Coyote/1.1
    Cache-Control: no-store
    Content-Type: application/json;charset=UTF-8
    Transfer-Encoding: chunked
    Date: Fri, 09 Sep 2011 12:32:34 GMT
    
    50
    {
      "error": "invalid_client",
      "error_description": "Client secret mismatch"
    }
    0
    And this is our clients configuration in our applications security.xml

    Code:
            <!-- tokenServices is an oauth in memory implementation -->
    	<oauth:provider resource-id="api" 
    		client-details-service-ref="clientDetailsService" 
    		token-services-ref="tokenServices">
    		<oauth:authorization-code user-approval-page="/oauth/confirm_access"/>
    	</oauth:provider>
    
    	<!-- TODO code based config -->
    	<oauth:client-details-service id="clientDetailsService">
    		<oauth:client 
    			clientId="client" 
    			resource-ids="api"
    			secret="secret" 
    			authorizedGrantTypes="authorization_code" 
    			authorities="ROLE_CLIENT"
    			scope="read,write" />	
    					
    	</oauth:client-details-service>
    You possibly hate me right now, but any advice appreciated
    Last edited by davidfoley; Sep 9th, 2011, 07:55 AM.

    Comment


    • #17
      I guess your client doesn't send the same data as tonr then? You are going to have to help me to understand the difference, and then we can work out which one is following the spec. The POST you list is the token endpoint exchange, right (the back channel)? It looks correct (but has more parameters than tonr would include). The mismatch seems to tell us that the secret wasn't included in the earlier request, which you haven't listed, to /oauth/user/authorize (the one that sends a redirect to get the user's approval).
      Last edited by Dave Syer; Sep 9th, 2011, 08:14 AM. Reason: typo

      Comment


      • #18
        Thats what we're thinking, and still trying to establish. I'll post a tonr-sparklr exchange for comparison against a php-sparklr exchange ASAP.

        Comment


        • #19
          I looked at the spec again and realised I had been too strict. If you can try again now, I think you will find that the authorization request does not require the client secret (and that's probably what your PHP client is doing).

          Comment


          • #20
            Hi Dave, thanks a million, we really appreciate the time and assistance you've provided here, and hopefully it will be of use to other members of the community- thats working for us now. One final question- could you confirm that the reference specification for the current Oauth2 implementation is Oauth 2 rev 21? We're assuming so on the basis of the link available on the OAuth homepage (in the other links section).

            Thanks and best wishes,

            Dave

            Comment


            • #21
              Yes, v21 is supposed to be the target at the minute, but as you know it's a bit of a moving goalpost. I don't think we are 100% compliant, but it basically works for most use cases that we claim to cover (i.e. the grant types and flows that we support).

              Comment


              • #22
                Thanks for confirming that-
                v21 is supposed to be the target at the minute, but as you know it's a bit of a moving goalpost
                Absolutely- its no walk in the park by any means- respect for undertaking it and the time you've given me- thanks Dave

                Comment


                • #23
                  Thanks to both of you for clearing this up!! Made my day.

                  Cheers
                  bjorn

                  Comment

                  Working...
                  X