Announcement Announcement Module
No announcement yet.
error:insufficient_scope after accessing a resource with bearer Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • error:insufficient_scope after accessing a resource with bearer

    After a successfull two way handshake is my client not able to access a protected resource. I allways get a insufficient_scope error.

    Answere after two way handshake:
    {"access_token":"37ded4d3-5278-40b7-b55d-573143d586c7","token_type":"bearer","refresh_token ":"9f772624-cca0-489c-8ba9-e88ccdbf361a","expires_in":43199}

    Request header of the resource request:
    GET /backed/rest/ping HTTP/1.1
    Accept: text/plain, application/json, */*
    Authorization: Bearer 37ded4d3-5278-40b7-b55d-573143d586c7

    Answere from the server:
    WWW-Authenticate: Bearer realm="myprotectedresource", error="insufficient_scope", error_description="Insufficient scope for this resource scopes", scope="SCOPE_TRUST"

    I guess that OAuth can not read the authorization bearer from the resource request authorization header. Can that be possible? Any other solutions for this?
    Last edited by adrian.hoehn; Jun 14th, 2012, 06:10 AM.

  • #2
    Your resource server appears to be implemented using Spring Security OAuth (I think I recognize that WWW-Authenticate header). If so then it is just telling you that the token you gave it has insufficient scope, and that a scope of "trust" would be sufficient if you felt like getting a new token to present.

    P.S. SCOPE_TRUST is an artifact of using the ScopeVoter - it doesn't know the actual names of the scopes, just the granted authorities it is matching. I feel like maybe we should fix it, but that's irrelevant for your question I think.


    • #3
      Thanks Dave. Haven't seen that I've forgot to send a scope.


      • #4
        I see. In that case I might have expected, depending on what version of the code your Auth server is using, to either not grant a token at all, or grant it with a default set of scopes. In the latter case you would either have the "trust" scope in your token or not, depending on whether it is permitted for your client. Maybe you actually did ask for a scope originally but it was the wrong one?


        • #5
          Omitting scope=trust while getting access token causes this.