Support for OAuth2 Client Credential flow

[Rob Higginbotham]

I am currently working on a solution that does not have a human interaction component as it relates to sage because it is aggregating data from a few different applications our company uses to create a high level overview. Currently the Authorization Flow with MFA and/or trusted devices doesn't easily allow for machine-to-machine API integrations. Am I possibly missing something or is there a workaround to requiring the trusted device or any plans to allow client credentials flow, which would be ideal?

[Elissa Williams]

We also have multiple solutions that do not have a human interaction component. We rely heavily on the client credentials for our authorization, which is listed as one of the most commonly used OAuth 2 grant types (https://oauth.net/2/grant-types/). Our team is struggling to find an approach to generate and manage access/refresh tokens without the users interaction, along with knowing how to tie this to a specific company ID. Is there any detailed documentation on how Intacct suggests that we set this up, or sample projects we can use as a reference? 

[Simon Trigona]

I'm in the same boat and as a result, have not seriously looked into switching to the new API. My understanding on the required approach would be something like:

Provide a URL/website to your client to run through the authentication flow. Store the generated token for your background service. When it expires, repeat.

1. Provide a URL/website that your client will use to authenticate your app.
2. Have the callback URL setup to your website/service.
3. Capture the access/refresh tokens & store in your database.
4. Use these values as long as you can.
5. When they expire (or proactively before they expire), email your client a notification with the URL from step 1 to re-authenticate.
6. Repeat.

That being said, based on reading some other forum posts, if I'm understanding correctly, the refresh token should be refreshed/have its expiry extended by 90 days every time its used. So it should be valid indefinitely. I did ask for clarification on this in the following thread.

 

[Sterio, Louis]

@Simon Trigona If you continually exchange the token within the 90 days. You won't need to reauthenticate.

[Lee Savidge]

12 hours ago, Sterio, Louis said:

@Simon Trigona If you continually exchange the token within the 90 days. You won't need to reauthenticate.

I have other systems that use OAUTH and they suffer with the issue that on occasion the token exchange fails in one way or another. Maybe it failed to store the new tokens. Maybe there was a problem in the communications, like a timeout. Then you have a mismatch of the tokens expected by the server and the tokens supplied by the client. The problem is then, how you generate new tokens. Without human interaction between my customer and us, there isn't a way to do it. It will still require someone to manually copy the tokens.

This is what is stopping me moving to the new REST API. The end user experience for my customers is what counts, and if they can't re-authenticate without us supporting a manual update of the tokens, it's dead in the water.

 

Lee

 

 

[Rob Higginbotham]

15 hours ago, Sterio, Louis said:

@Simon Trigona If you continually exchange the token within the 90 days. You won't need to reauthenticate.

Respectfully, this still doesn't solve the initial human interaction requirement and doesn't offer an enterprise level solution as it's quite fragile.. As @Elissa Williams noted above, for machine to machine, which it seems a number of us require, Client Credentials flow is the standard. Can we please get a response to the original question about also supporting Client Credential in addition to Authorization Flow?

Although this is an Okta reference, it's one of the most clear:
(https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-credentials-flow)

So as not to seem like a complete detractor, this api is exactly what I am in need of and I'm very hopeful to be able to utilize it. Without a solution to this though I'm unlikely to be able to move forward.

[Rob Higginbotham]

Also, I also just came across a previous post (linked below) which was requesting the client credentials grant as well. In reading the response there I noted that the response was that the api would not be supporting "password grant" (which is a smart choice) but "password grant" is not the same as "client credential grant". I only wanted to point that out to ensure we as the dev community here were being clear in what we were requesting.
 

 

[Sterio, Louis]

Thank you for the detailed discussions and for sharing your concerns regarding machine-to-machine (M2M) API integrations and the challenges around the Authorization Flow with MFA/trusted devices. I want to share that the following information comes directly from our engineering and architecture teams. Please note that there are still active discussions on what we will support long term.

To address the main points:

1. Current API Authentication Model: Our Intacct REST endpoints currently require user-based access tokens and a user session. This is primarily designed to ensure that all actions are performed within a specific user context, which helps us manage routing, company-specific data access, and other security measures.

2. Challenges with Client Credentials Flow: Implementing native M2M tokens (i.e., the Client Credentials Flow) for Intacct is complex. Our engineering and architecture teams have indicated that significant changes would be required to support the context-free nature of M2M communication, including:

   • Indicating that a client is M2M within the developer portal.
   • Passing company and user information via HTTP headers to maintain the security and integrity of tenant data.
   • Managing permissions to ensure that third parties are not granted blanket access to all tenant data.

3. OAuth2 and Client Credentials Flow: While OAuth2's Client Credentials Flow is commonly used for third-party applications accessing their own data, in the context of Intacct, this flow does not grant access to tenant-specific data. Our OAuth2 implementation is designed for third-party applications to obtain explicit tenant permission before accessing tenant data.

Your feedback is invaluable in shaping our discussions, and we’ll keep the community updated on any developments in this area. Thank you for your engagement and continued support.

[Rob Higginbotham]

Thank you for the response and I understand those concerns. To your 3rd point above, that's exactly what we're needing to accomplish, access our own data, specifically from Azure Fabric for our own internal purposes, not developing an application integration for distribution.

I would say that most 3rd party systems I integrate with offer client credential for that purpose and those credentials are generated in the context of a specific user account so the authorizations are managed exactly the same as if it were a typical user. I would assume such an account already belongs to a given tenant and as such has specific accesses and permissions, etc.

Just a use case that I would really urge the team to consider. Thanks again

[Sterio, Louis]

Rob,

Good news! 

We understand the need here are discussing how we can deliver an Intacct flavor of client credential with the Architects. Discussions are underway, I am confident we will have a solution here, probably not on day 1 of production availability. Stay tuned, I will update this thread when something is scheduled and I know  more.

[Tyson Kluwe]

I also agree Client Credential flow is the standard and it should be added.  There is a reason its in the docs.  I will not be using the REST API without this feature.

[Sterio, Louis]

1 minute ago, Tyson Kluwe said:

I also agree Client Credential flow is the standard and it should be added.  There is a reason its in the docs.  I will not be using the REST API without this feature.

Thanks for your feedback. Discussions are underway.