OAuth2 Invalid grant error on access token endPoint

This topic has 26 replies, 3 voices, and was last updated 5 years, 2 months ago by anta.

  • Author
    Posts
  • #18024
     anta
    Participant

    Hi there,

    I’m using OpenAm with an OpenDj datasource.
    When I’m calling access token endpoint :
    https://{{host}}/openam/oauth2/access_token?realm=/{{reaml}}

    I’m getting a 400 bad request error with the response :
    {
    “error_description”: “The provided access grant is invalid, expired, or revoked.”,
    “error”: “invalid_grant”
    }

    Can anybody help me with this please ?

    #18025
     Andy Cory
    Participant

    Which OAuth2 flow are you using? Is it the authorisation code grant flow? If so, your previous request should have been to the /authorize endpoint, and you should have received an authorisation code that you would use in the request to the access_token endpoint. One explanation for the message you are getting is that the code is wrong, missing, or the expiry time has passed. That’s only one explanation, though. You’ll need to give us more info to do any better.

    Andy

    #18035
     Scott Heger
    Participant

    It would help if you could provide the entire call that you are making to the access_token endpoint. Are you doing a GET or POST plus what other data and/or headers are you sending?

    #18047
     anta
    Participant

    For the OAuth2, I’m using the Username-Password flow and the entire call I’m making is :

    curl -X POST
      'https://openam.tech.aws.info:8443/openam/oauth2/access_token?realm=%2Ftech' 
      -H 'authorization: Basic b2F1dGhBZ2VudDp5dXZ3ODlmKioq' 
      -H 'content-type: application/x-www-form-urlencoded'
    #18054
     Andy Cory
    Participant

    That request doesn’t look it contains like enough info. I think you are looking to use the “Resource Owner Password Credentials” grant, but there’s no grant_type specified in the request, and no indication of which OAuth2 client profile covers the request. The docs at https://backstage.forgerock.com/docs/openam/13.5/dev-guide#sec-rest-oauth2-oidc may help.

    Andy

    #18056
     anta
    Participant

    My bad, the request I sent doesn’t have the body. Here is the full http request :

    POST /openam/oauth2/access_token?realm=/tech HTTP/1.1
    Host: openam.tech.aws.info:8443
    Authorization: Basic b2F1dGhBZ2VudDp5dXZ3ODlmZioq
    Content-Type: application/x-www-form-urlencoded
    
    username=user&password=pwd&grant_type=password
    #18061
     Andy Cory
    Participant

    Hmm, that should work. I tried this against a test VM I have running at the moment:

    POST /idauth/oauth2/access_token?realm=customers HTTP/1.1
    Content-Type: application/x-www-form-urlencoded
    Authorization: Basic c2FnZTpQOWJZMzV0V3lORFA=
    Host: openam.example.com:8443
    Connection: close
    User-Agent: Paw/3.1.1 (Macintosh; OS X/10.12.5) GCDHTTPRequest
    Content-Length: 66

    grant_type=password&username=perry.penguin&password=secretpassword

    The basic auth header being the client_id and client_secret of my Oauth2 client profile. For me, I got the expected response:

    {
    “access_token”: “9668f507-34e4-442f-bb8a-7930535417ac”,
    “refresh_token”: “f3cb7b68-35a7-4d4b-b315-f0a291d964df”,
    “scope”: “cn”,
    “token_type”: “Bearer”,
    “expires_in”: 599
    }

    Is there anything in the debug logs at Message level that throws any light?

    Andy

    #18073
     Scott Heger
    Participant

    Which version of OpenAM are you using?

    #18074
     Scott Heger
    Participant

    Versions prior to AM 5.x can give you that response when the user credentials are wrong. See https://bugster.forgerock.org/jira/browse/OPENAM-8790. A good test would be to ensure that you can log into your OpenAM console with the user credentials you are using in your OAuth ROPC call. Just be sure to specify the realm in your login URL (i.e. https://openam.tech.aws.info:8443/openam/auth/XUI/?realm=/tech#login/)

    #18093
     anta
    Participant

    The version of OpenAm is 14.0.0. When I try to login with the user credentials into the OpenAm console it fails. So I checked the logs :

    in authentication.csv I have :

    "2017-07-12T18:28:36.311Z","AM-LOGIN-MODULE-COMPLETED","4cfe092e-415b-4fb4-b52a-70645875e5bd-5791","id=user,ou=user,o=tech,ou=services,dc=openam,dc=forgerock,dc=org","[""7385f2c3e0e3fb8e01""]","FAILED","[""user""]",,"[{""moduleId"":""LDAP"",""info"":{""authControlFlag"":""REQUISITE"",""moduleClass"":""LDAP"",""ipAddress"":""86.245.31.178"",""authLevel"":""0""}}]","Authentication","/tech"
    "4cfe092e-415b-4fb4-b52a-70645875e5bd-5795","2017-07-12T18:28:36.311Z","AM-LOGIN-COMPLETED","4cfe092e-415b-4fb4-b52a-70645875e5bd-5791",,"[""7385f2c3e0e3fb8e01""]","FAILED",,,"[{""moduleId"":""LDAP"",""info"":{""failureReason"":""LOGIN_FAILED"",""ipAddress"":""86.245.31.178"",""authLevel"":""0""}}]","Authentication","/tech"

    I can find the user in the subjects when I access the realm

    #18094
     anta
    Participant

    in access.csv :

    "2017-07-12T18:28:36.313Z","AM-ACCESS-OUTCOME","4cfe092e-415b-4fb4-b52a-70645875e5bd-5791",,,"172.17.0.2","8443","86.245.31.178","59820",,,,"true","POST","https://openam.tech.aws.info:8443/openam/oauth2/access_token","{""realm"":[""/tech""]}","{""accept"":[""*/*""],""host"":[""openam.tech.aws.info:8443""],""origin"":[""chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop""],""postman-token"":[""1ac0811c-e9fa-754d-c146-434a9e7eb7a5""],""user-agent"":[""Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36""]}","{}",,"FAILED","400","{""reason"":""The request could not be understood by the server due to malformed syntax""}","8","MILLISECONDS","OAuth","/tech"

    I also found this : https://bugster.forgerock.org/jira/browse/OPENAM-8302

    #18096
     Scott Heger
    Participant

    Can you check your LDAP authentication module in your /tech realm and see if your “DN to Start User Search” is set to “dc=openam,dc=forgerock,dc=org”? If it is, change it to the proper DN for your LDAP server.

    #18097
     anta
    Participant

    in the config files : amAuthLDAP.xml and amAuthAD.xml I have the “DN to Start User Search”(iplanet-am-auth-ldap-base-dn) set to
    a different value : “dc=xxxx,dc=com”. But I don’t understand while the DN used by my access token endpoint is “dc=openam,dc=forgerock,dc=org”. Do I need to change the “Persistent Search Controls” in the openAM console which is set to “dc=openam,dc=forgerock,dc=org” ?

    #18098
     Scott Heger
    Participant

    Yes your Persistent Search Controls should be set to your Data Store DN, but I don’t believe that would be the cause of the issue here. While you have the values in those XML files, can you validate via the OpenAM console how that DN to Start User Search is configured in your LDAP module?

    #18100
     anta
    Participant

    I’m not sure where to find the info in the openAm console. I was looking in my OpenDj configuration (where I found the “Persistent Search Controls”).

    I tried to change the “Persistent Search Controls” value but I still have the DN “dc=openam,dc=forgerock,dc=org” in the authentication logs.

Viewing 15 posts - 1 through 15 (of 25 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?