Skip to main content

Authentication

Authentication against our Banking API is performed via an OAuth 2.0 client credentials grant flow.

Use the client credentials (ID and secret) provided to you during onboarding to make a request to our /token endpoint to generate an access_token.

$ curl https://api.test.figurepay.com/oauth2/token \
       -H 'Accept: application/json' \
       -H 'Content-Type: application/x-www-form-urlencoded' \
       --data "client_id=abc" \
       --data "client_secret=xyz" \
       --data "grant_type=client_credentials"

{
  "access_token": "FOEtUHwg0das9PhsasVmgMGbZn7nWSgK"
}

The access_token is then placed in an HTTP Bearer authentication header for subsequent requests to our API.

$ curl https://api.test.figurepay.com/profiles \
  -H 'Authorization: Bearer FOEtUHwg0das9PhsasVmgMGbZn7nWSgK'
  ...

An access_token expires after one hour. Subsequent request will produce an HTTP 401 response until your client application re-authenticates using the above /token endpoint.

Client credentials are unique per environment. Please make sure you are using the right credentials with the right environment URL to successfully perform authentication.

OAuth 2.0 Client Credentials Flow

Security Best Practices​

Below are best practices for securely storing and managing your API credentials. It is important to consider that any lost or stolen API credentials can result in authorized access to your user's personal information, their accounts, and any entity associated with your program, so it's essential to keep your credentials secured.

If you suspect that your API credentials or an access_token has been leaked, please contact our support team immediately. We will temporarily deactivate your account access in order to prevent any further unauthorized access.

Client Credentials​

Client credentials are long-lived API credentials that allow you to generate short-lived tokens for accessing our API.

Client credentials resemble a username and password. A Client ID can be freely shared but your client secret should never be shared. This includes storing the secret as plaintext through a version control system, as well as storing them in any web or mobile client application. Similarly, your secret should not be shared unencrypted over email or instant message.

Client credentials should only be accessible by your servers and always encrypted at-rest and in-transit over HTTPS.

When providing your client credentials to the /token endpoint in exchange for an access_token, only provide the client secret via the POST body to ensure encryption in-transit over SSL.

Access Tokens​

Access tokens are opaque tokens used to authenticate your API requests. They are short-lived tokens that, if lost, will invalidate themselves on expiry.

Access tokens do not need to be persisted by your application as they are ephemeral. Similarly, access tokens should not be shared as plaintext in the same ways that your client secret shouldn't be shared.

Access tokens should only be transmitted over HTTPS and should be excluded from URL query parameters.