Application security

At Sage Intacct, we take the privacy of our customers and their data very seriously. When we grant access to APIs, we expect developers to take privacy and security just as seriously as we do. Read this page 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 authorization code flow

Sage Intacct uses the OAuth 2.0 authorization code grant type (also called the authorization code flow) to allow API clients to obtain secure, authenticated access to our web services on behalf of specific resource owners. The flow goes through these steps:

  1. A user indicates that they want to use your application with Sage Intacct.
  2. Your application sends an authorization request to our authorization endpoint.
  3. The user is directed to a Sage Intacct sign-in page, where they must sign in to their company with their username and password.
  4. After signing in, the user sees a page that tells them that your application wants to access Sage Intacct on their behalf, and they must click a button to allow that access. Note that your application will have the same permissions and restrictions as the authorizing user.
  5. The authentication server sends an authentication code back to your application at a specified callback URL.
  6. Your application then sends that code in the header of an access request to our token endpoint.
  7. Our server sends an access token and a refresh token to your application.
  8. Your application uses the access token in the header of any API requests.
  9. When the access token expires, your application uses the refresh token to obtain a new access token.

Data access without using user credentials

The OAuth 2.0 authorization code flow allows your application to access Sage Intacct data on behalf of a user without needing to have the user's credentials. Because of this protocol, users are ensured that applications that interact with Sage Intacct protect their privacy and security.

Roles and permissions

The Sage Intacct system uses user roles and permissions to define the application areas and data that users can access and change. Through the OAuth 2.0 authorization code flow, your application will have the authorization of a specific user for each session, and thus will have the same permissions as that user.

Note: To limit exposure and reduce risk, you may want to create Sage Intacct users that only have access to the Sage Intacct application areas and data required by your application.

Client ID and secret key security

When you register your application with Sage Intacct, you receive a client ID and secret key.

  • The client ID identifies your application and does not change. You must include the ID in the header of every request.
  • 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. For example, configuration files, include files, and so on.
  • Do not record it in log files or error messages.

Remember that 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

Access tokens allow your application to access 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 sensitive information, 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 authentication flow

We require HTTPS connections for all 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 for your site. 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, our 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.