Skip to main content

Hey guys,

Hopefully I can get some help on the topic.

 

Currently we use Authorization Code to generate an Access Token.

We help the client setup a new Connected Application

In the Flow, we choose Authorization Code

We setup a new Shared Secret and we set the Redirect URI to be our server

 

from our application we store the Clients URL, ClientID and Shared Secret and use them as follows

We then load the following URL on the client side

https://*CLIENT_URL/identity/connect/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=api offline_access&state=CLIENT_CODE

 

This redirects the client to the website asking them to authorize.

Once done, the client is redirected to our server and the server will store the following

access_token

expires_in

refresh_token

 

When the access token has expires, we then use the stored refresh_token to generate access_token like this

Method: POST

https://*CLIENT_URL/identity/connect/token

Post Data

client_id: CLIENT_ID

client_secret: CLIENT_SECRET

refresh_token: REFRESH_TOKEN

grant_type: refresh_token

 

This will return back a new access_token, expires_in and refresh_token.

 

We are finding that clients are recieving the below error at different times, sometimes it can work for 2 weeks, other times only 3-4 days.

{"error":"invalid_grant"}

 

Is there something we are doing wrong here or is there an alternative way to get a new Access token without having to repeat the process of having the client Re-authorize?

Hi @mattollie ,

Did you try using the refresh token option below?



 

Element Description
Mode The mode of expiration of refresh tokens. You can select one of the following options:
  • Absolute Expiration: A refresh token expires when the total number of days in the refresh token’s lifetime (from its initial issuing) exceeds the number of days that is specified in the Absolute Lifetime (Days) box.
  • Sliding Expiration: The lifetime of the refresh token can be extended multiple times by the period of the sliding lifetime, which is specified in the Sliding Lifetime (Days) box. The refresh token can be extended until its total lifetime (from its initial issuing) exceeds the number of days that is specified in the Absolute Lifetime (Days) box. If the Infinite check box is selected for the absolute lifetime, the lifetime of the refresh token can be extended endlessly. For details about how the sliding expiration works, see Sliding Expiration of Refresh Tokens.
  • No Refresh Tokens: The system does not issue refresh tokens. If a connected application requests the offline_access scope (that is, requests that a refresh token be granted), an error is returned.
By default, Absolute Expiration is selected. If Absolute Expiration is selected, only Mode and Absolute Lifetime (Days) appear in this section. If No Refresh Tokens is selected, only Mode appears in this section.
Absolute Lifetime (Days) The number of days after which the user must reauthenticate and grant permissions to a connected application so that the application can continue working with Acumatica ERP.If Absolute Expiration is selected in the Mode box, the default absolute lifetime is 30 days. You can specify any number of days from 1 to 60.
If Sliding Expiration is selected in the Mode box, the default absolute lifetime is 90 days. You can specify any number of days from 1 to 365.
The box appears only if Absolute Expiration or Sliding Expiration is selected in the Mode box.
Infinite A check box that indicates (if selected) that the absolute lifetime is infinite.By default, this check box is cleared. If the check box is selected, the Absolute Lifetime (Days) box is unavailable for editing.
The check box appears only if Sliding Expiration is selected in the Mode box.
Sliding Lifetime (Days) The number of days that extends the lifetime of a refresh token. The default sliding lifetime is 15 days. You can specify any number of days from 1 to 60.The check box appears only if Sliding Expiration is selected in the Mode box.

Hi @mattollie 

At the first  glance, I don’t see any issue with your approach.

Here are the things I’d check in this case:

  • replicate the request in a Rest API Client (i.e. Postman, Thunder Client, etc.) and see how it works
  • debug token refresh call to compare generated request right before it is send and check if all headers and body are properly set
  • check the persisting logic - maybe you’re not saving the latest refresh token for some reason
  • check the platform you’re connecting to - maybe there are logs that will allow you to see something odd. Maybe you have a conflict with another integration?
  • re-read documentation. I was receiving this error once when my grant_type header wasn’t properly formed. Maybe the refresh token is so short-lived?

I had to develop integration where access token had lifetime of 15 minutes, and our process could work for way longer that it. So I implemented a routine check into our API client, to see if Expiry Time is already met, if so - renew the token.


Hi @mattollie ,

Did you try using the refresh token option below?



 

Element Description
Mode The mode of expiration of refresh tokens. You can select one of the following options:
  • Absolute Expiration: A refresh token expires when the total number of days in the refresh token’s lifetime (from its initial issuing) exceeds the number of days that is specified in the Absolute Lifetime (Days) box.
  • Sliding Expiration: The lifetime of the refresh token can be extended multiple times by the period of the sliding lifetime, which is specified in the Sliding Lifetime (Days) box. The refresh token can be extended until its total lifetime (from its initial issuing) exceeds the number of days that is specified in the Absolute Lifetime (Days) box. If the Infinite check box is selected for the absolute lifetime, the lifetime of the refresh token can be extended endlessly. For details about how the sliding expiration works, see Sliding Expiration of Refresh Tokens.
  • No Refresh Tokens: The system does not issue refresh tokens. If a connected application requests the offline_access scope (that is, requests that a refresh token be granted), an error is returned.
By default, Absolute Expiration is selected. If Absolute Expiration is selected, only Mode and Absolute Lifetime (Days) appear in this section. If No Refresh Tokens is selected, only Mode appears in this section.
Absolute Lifetime (Days) The number of days after which the user must reauthenticate and grant permissions to a connected application so that the application can continue working with Acumatica ERP.If Absolute Expiration is selected in the Mode box, the default absolute lifetime is 30 days. You can specify any number of days from 1 to 60.
If Sliding Expiration is selected in the Mode box, the default absolute lifetime is 90 days. You can specify any number of days from 1 to 365.
The box appears only if Absolute Expiration or Sliding Expiration is selected in the Mode box.
Infinite A check box that indicates (if selected) that the absolute lifetime is infinite.By default, this check box is cleared. If the check box is selected, the Absolute Lifetime (Days) box is unavailable for editing.
The check box appears only if Sliding Expiration is selected in the Mode box.
Sliding Lifetime (Days) The number of days that extends the lifetime of a refresh token. The default sliding lifetime is 15 days. You can specify any number of days from 1 to 60.The check box appears only if Sliding Expiration is selected in the Mode box.

 

Hi Jinin,

Thank you for your prompt response.

I do not have access to that REFRESH TOKENS section in my version

Is this something that is coming to a new version?

 


Hi @mattollie 

At the first  glance, I don’t see any issue with your approach.

Here are the things I’d check in this case:

  • replicate the request in a Rest API Client (i.e. Postman, Thunder Client, etc.) and see how it works
  • debug token refresh call to compare generated request right before it is send and check if all headers and body are properly set
  • check the persisting logic - maybe you’re not saving the latest refresh token for some reason
  • check the platform you’re connecting to - maybe there are logs that will allow you to see something odd. Maybe you have a conflict with another integration?
  • re-read documentation. I was receiving this error once when my grant_type header wasn’t properly formed. Maybe the refresh token is so short-lived?

I had to develop integration where access token had lifetime of 15 minutes, and our process could work for way longer that it. So I implemented a routine check into our API client, to see if Expiry Time is already met, if so - renew the token.

Hi andriitkachenko,

Thank you for your response.

I am in the process of testing in Postman, but its quite difficult to test as it generates the token perfectly fine as I said, it is a random thing after either 4-5 days or a couple of weeks that the error is returned, so it will take quite a while to test.

I am logging every request to and every response from on our end and can see all the correct headers are in place, every refresh token used matches the one used in the next call to get the access token and I am not seeing any errors being returned that would show a failed request.

 

I was hoping maybe there was a different URL that we could call with the ClientID and Client Secret that would then allow us to generate a new refresh_token without the client having to re-authorize the application over and over.


@mattollie The parameter @jinin  refers to was added in 23R2


@mattollie have you had a chance to review following discussion:

gmail api - Using Refresh Token Exception { "error" : "invalid_grant" }' - Stack Overflow


@mattollie The parameter @jinin  refers to was added in 23R2

Hi dcomerford,

I had a look at the version I am on and it shows this.

I would assume given it was updated 31/01/2024 that it should be in there, but I cannot see that option in my environment, is there a setting somewhere that I am not seeing?

 

 


@mattollie have you had a chance to review following discussion:

gmail api - Using Refresh Token Exception { "error" : "invalid_grant" }' - Stack Overflow

Hi RohitRattan,

While looking at that link the only thing that could make sense is the server time not being in sync at the time of the call, but kind of don’t think that is the case as they can re-authenticate without any issues and refresh tokens work fine after that point.

We definitely aren't asking for more than 24 tokens in a 24 hour period, so don't think being throttled would be the issue.

We are using the same token received after refresh because I can see in the logs the call that token in the previous call matches that of the subsequent call. Maybe the refresh token is not valid and using that in a subsequent call is causing issues, but also doubtful.

 

I have added a server call to try the request again when invalid_grant is returned so we will see if that does anything different, if it returns invalid_grant again, it will automatically ask them to re-authenticate, which is not a desired result, but until I can fully figure out what is going on, will have do to for now.


@mattollie The parameter @jinin  refers to was added in 23R2

Hi dcomerford,

I had a look at the version I am on and it shows this.

I would assume given it was updated 31/01/2024 that it should be in there, but I cannot see that option in my environment, is there a setting somewhere that I am not seeing?

 

 


You are in Acumatica 23R1 build version (23.112.32). The Refresh token feature was introduced in the Acumatica build 23R2. 
​​​​​​​


@mattollie The parameter @jinin  refers to was added in 23R2

Hi dcomerford,

I had a look at the version I am on and it shows this.

I would assume given it was updated 31/01/2024 that it should be in there, but I cannot see that option in my environment, is there a setting somewhere that I am not seeing?

 

 


You are in Acumatica 23R1 build version (23.112.32). The Refresh token feature was introduced in the Acumatica build 23R2. 

Hi Jinin,

 

Thank you for your response, I will wait until that version is available to me to test and see if I can work out the Refresh Token isssue.


Using Postman, I’ve been looking into and testing the access token/refresh token in 23R1, and have found the following:

  1. Get Access token key for first time - authenticate via login and access is grant - response turn access key and refresh token key. Noting that one of the elements returned in response body is: "expires_in":3600

  2. Get/Post data using access key got from point 1 - all good

  3. After an hour or so, when tried to get/post data with access key got from point 1 - get message {"message":"You are not logged in."}

  4. Get new access token key with refresh token got from point 1 - response return new access key and new refresh token key

  5. Get/post data using new access key got from point 4 - all good

  6. After an hour or so, when tried to get/post data with access key from point 4 - get message {"message":"You are not logged in."}

  7. Get new access token key with refresh token key from point 1 - get response {"error":"invalid_grant"}

  8. Get new access token key with refresh token key from point 4 - response return new access key and new refresh token key

I’m waiting for new version to be available to me so I can test again.


Reply