Application security

At Sage Intacct, we take great care to protect the integrity and confidentiality of our customers and their data. Read this topic to understand how we protect data and the steps that you need to take in your client application to maintain a high level of data security.

OAuth 2.0

Sage Intacct uses the OAuth 2.0 authorization standard to allow REST API clients to obtain secure access to our web services on behalf of specific resource owners without exposing the user's credentials. Client applications can use the authorization code or the client credentials grant type depending on the type of access required.

The authorization code grant type (also called the authorization code flow) is supported for applications in which a user can click a button or link to grant the application access to their data in Sage Intacct. See Authorization code grant type for more information about the steps and requests involved with this flow.

The proof key for code exchange (PKCE) grant type is an extension of the OAuth 2.0 authorization code grant type. It adds an extra layer of security to prevent authorization code interception attacks. PKCE is recommended for mobile apps and public clients where storing the client secret is unsafe. See Authorization code grant type with PKCE flow for details.

The client credentials grant type is supported for applications needing direct access without user interaction. To use the client credentials grant type, the client application must be associated with a Web Services user and explicitly authorized in a company's configuration. See Client credentials grant type for details.

Additionally, OAuth 2.0 provides an ability to revoke access if a security concern arises. See Revoke a token for details.

Client ID and secret key security

When you register your application with Sage Intacct, you receive a client ID and secret key as described in the Get API keys topic.

  • The client ID identifies your application and does not change. You must include the client ID in the header or in the payload of token requests .
  • The secret key validates that authentication requests are sent from your application and are not being spoofed by someone else, as only you (your company) should know the secret key. You can generate a new key at the app registry whenever you need one.

To keep the secret key safe:

  • Do not store it locally on a mobile device.
  • Do not expose it in files such as JavaScript or HTML files in client-side code.
  • Do not store it in files on a web server that can be viewed externally, such as configuration files, include files, and so on.
  • Do not record it in log files or error messages.

When exchanging an OAuth 2.0 authorization code for an access token, the secret key is passed as part of the request. Make sure you do not expose this request publicly.

Access token security

OAuth 2.0 uses access tokens to grant your application access to a company's Sage Intacct data. To keep access tokens safe:

  • Do not store them in insecure or easily accessible locations. Client-side files, such as JavaScript or HTML files, should never be used to store access tokens, as these can easily be accessed.
  • Do not store access tokens in code files that can be decompiled, such as Native iOS, Android, or Windows application code files.

Secure requests with HTTPS

Sage Intacct requires HTTPS connections for all requests (including authentication requests) to prevent others from reading your requests and to prevent man-in-the-middle attacks. Your application must also be hosted on a secure server, particularly for pages where a user enters private information, such as their password. We also require HTTPS for the redirect URIs used in the OAuth authorization flow.

Cross-site request forgery

Use the state parameter to protect against cross-site request forgery (CSRF) attacks during authorization. Send a state string value in each authentication request that is unique, difficult to guess, and does not contain private or sensitive information. After the user authenticates, the authentication server will include the state value when sending a request to your callback URL. Your application should verify that the state parameter in the response matches the one you passed in your authorization request. If the state does not match, the request may be a result of CSRF and should be rejected. See Authorization code request for details.

Roles and permissions

Sage Intacct employs user roles and permissions to define the application areas and data that users can access and modify. Through the OAuth 2.0 authorization code flow, your application will have the authorization of a specific user for each session, and thus inherit the same permissions as that user. See Permissions overview in the Sage Intacct Help Center for details.

As best practice, to limit exposure and reduce risk, create Sage Intacct users that only have access to the Sage Intacct application areas and data required by your application. See the user roles and permissions objects in the Company configuration module for more information.