SailPoint OAuth
How OAuth secures SailPoint API access with client credentials and tokens.
SailPoint APIs use OAuth 2.0: a client obtains an access token (often via client credentials) and sends it as a bearer token on each call.
- OAuth 2.0 secures the APIs
- Client credentials grant for service integrations
- Access tokens are short-lived bearer tokens
- Scopes limit what a token can do
OAuth 2.0 secures the SailPoint APIs. Rather than sending a username and password on every call, a client obtains a short-lived access token and presents it as a bearer token. For machine-to-machine integrations, the client-credentials grant is the standard.
Getting a token
Register a client (obtaining a client ID and secret), then exchange those for an access token at the token endpoint:
POST /oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_id=...&client_secret=...The response contains an access_token and an expiry. Send the token on each API request as Authorization: Bearer <token>.
Scopes and least privilege
Tokens can be scoped so a client only has the permissions it needs. Request the minimum scopes for the integration’s job, a reporting integration should not hold provisioning rights. This limits the blast-radius if a credential leaks.
Handling tokens safely
- Store the client secret securely, in a secrets manager, never in source control or client-side code.
- Cache the token until near expiry, then refresh, rather than authenticating on every call.
- Re-authenticate on
401in case the token has expired or been revoked.
Common pitfalls
- Secrets embedded in code or images.
- Over-scoped tokens granting more than the integration needs.
- Requesting a new token per call, wasteful and rate-limit-prone.