Redirect URI as a full https URL to get Intacct Token

[Greg Gleason]

Will the new Rest API always require a public URL to retrieve the Auth Token?  All my code is held in a private network.  How will I be able to retrieve the Token?  Thanks.  Greg

[Sterio, Louis]

Greg,

May I ask how you are doing this with the XML API today? Also have you tried to connect to a non-production company via the REST API?

Let me know where you are getting an error or where you are getting stuck. I am moving this thread to REST Open beta Feedback

[Preston, Charlie]

Louis, I was going to ask you about this – but will ask here instead as it relates to what Greg is asking.

In the original beta there was an end point to retrieve a token by passing in the user/instance/password and receiving a token back directly in the response – this method is useful when writing scripts or desktop applications where you aren’t running a web server to receive a response from a callback.

Is it still ok to use the original oauth2/token endpoint?  I can see it still works, but as it’s not documented wanted to check.

Thanks, Charlie

[Preston, Charlie]

I'll reword that last question so it makes more sense - should have been "Is it still ok to use the original oauth2/token endpoint and pass in the user name / password rather than the authorisation code?"

[Sterio, Louis]

Charlie,

That was using the "password" grant_type we are removing this grant_type in 24R3 (August timeframe) and we did not document it on purpose. We only want to allow authentication with OAUTH. When we remove this grant_type in R3 we will also be implementing new expiration rules related to our refresh_token. We will be documenting this as well. 

Here is what is changing:

1.) Previously refresh tokens would expire after 365 days no matter what. This would force re-authorization through OAUTH to all integrations after 365 days. We realize this is not going to work.

2.) After 24R3 we will shorten the expiration date to 90 days and as you exchange your refresh token for a new access token we will push the expiration of the refresh token out another 90 days.

 

[Sterio, Louis]

@Greg Gleason We're discussing this further tomorrow in our weekly meeting however for now you could use postman to OAUTH, and load the refresh token into your utility. Then you can exchange the refresh token for an access token each time the utility wakes up. However look for more of an official response from us in the near future.

[Benito Gomez]

On 5/15/2024 at 11:14 AM, Sterio, Louis said:

@Greg Gleason We're discussing this further tomorrow in our weekly meeting however for now you could use postman to OAUTH, and load the refresh token into your utility. Then you can exchange the refresh token for an access token each time the utility wakes up. However look for more of an official response from us in the near future.

Did you have an official response to this topic? I was digging through the REST documentation but couldn't find a direct answer to more of a daemon management for these tokens. 

[Simon Trigona]

On 5/15/2024 at 8:57 AM, Sterio, Louis said:

Charlie,

That was using the "password" grant_type we are removing this grant_type in 24R3 (August timeframe) and we did not document it on purpose. We only want to allow authentication with OAUTH. When we remove this grant_type in R3 we will also be implementing new expiration rules related to our refresh_token. We will be documenting this as well. 

Here is what is changing:

1.) Previously refresh tokens would expire after 365 days no matter what. This would force re-authorization through OAUTH to all integrations after 365 days. We realize this is not going to work.

2.) After 24R3 we will shorten the expiration date to 90 days and as you exchange your refresh token for a new access token we will push the expiration of the refresh token out another 90 days.

 

Am I reading item 2 correctly, in that the refresh token will expire after 90 days, HOWEVER, every time you use the refresh token to get a new access token, you will get a new refresh token that is valid for another 90 days?

In other words, as long as you keep using your refresh token, it will remain valid and you won't have to reauthenticate with your client. If you don't use it for 90+ days, then it'll expire.

Would it be possible to get this info added to the documentation site? I assume it would go here: https://developer.sage.com/intacct/docs/developer-portal/guides/security/

Thanks in advance,

Simon

[Sterio, Louis]

12 minutes ago, Simon Trigona said:

Am I reading item 2 correctly, in that the refresh token will expire after 90 days, HOWEVER, every time you use the refresh token to get a new access token, you will get a new refresh token that is valid for another 90 days?

In other words, as long as you keep using your refresh token, it will remain valid and you won't have to reauthenticate with your client. If you don't use it for 90+ days, then it'll expire.

Would it be possible to get this info added to the documentation site? I assume it would go here: https://developer.sage.com/intacct/docs/developer-portal/guides/security/

Thanks in advance,

Simon

Yes, that's correct. Upon authentication, you'll receive both an access token and a refresh token. When you use the refresh token to obtain a new access token, a new refresh token will also be issued. You'll need to save this new refresh token for the next time you need to refresh the access token. Each time you perform this token exchange, the expiration date will reset, extending it for another 90 days.

[Simon Trigona]

Ok great! A few more questions if you don't mind:

• Can a refresh token be used more than once?
• If the response for a refresh is lost due to some service disruption (ex: timeout, internet issues, etc.), are we stuck needing to re-authenticate with the client?

[Sterio, Louis]

@Simon Trigona 

For your first point after R3 it looks like you cannot use the refresh token more than once. We will return a new refresh token with every exchange.

I am getting clarification from engineering on your second point and will let you know. If we don't have a grace period of some sort we should definitely have one or something similar which will not require re-authentication. I remember having this discussion internally some time back.