Skip to content
IT Canvass
Menu
ServiceNow
SailPoint
SAP
TutorialsContact
APIs & integration · Lesson

OAuth

Quick answer

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.

Key takeaways

  • 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 401 in 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.

Want to learn this properly?

Our live, instructor-led SailPoint Training covers this hands-on, with real projects and a certification path.

See the courseAsk a question

Check your understanding

  1. What secures SailPoint APIs?

    • A. Stored securely and never embedded in client-side code.
    • B. OAuth 2.0, using access tokens sent as bearer tokens.
    • C. The client-credentials grant, exchanging a client ID and secret for a token.
    Show answer

    B. OAuth 2.0, using access tokens sent as bearer tokens.

    OAuth 2.0, using access tokens sent as bearer tokens.

  2. Which grant do service integrations use?

    • A. OAuth 2.0, using access tokens sent as bearer tokens.
    • B. The client-credentials grant, exchanging a client ID and secret for a token.
    • C. Stored securely and never embedded in client-side code.
    Show answer

    B. The client-credentials grant, exchanging a client ID and secret for a token.

    The client-credentials grant, exchanging a client ID and secret for a token.

  3. How should secrets be handled?

    • A. The client-credentials grant, exchanging a client ID and secret for a token.
    • B. Stored securely and never embedded in client-side code.
    • C. OAuth 2.0, using access tokens sent as bearer tokens.
    Show answer

    B. Stored securely and never embedded in client-side code.

    Stored securely and never embedded in client-side code.

Frequently asked questions

What does the term OAuth refer to in SailPoint?

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.

What is another point to note about OAuth?

Send the token on each API request as Authorization: Bearer <token>.

What else is worth knowing about OAuth?

Tokens can be scoped so a client only has the permissions it needs.

What tends to go wrong with OAuth?

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.
CallWhatsAppEnquire