Client Credentials

SIS APIs use Microsoft Entra ID for application authentication. Server-to-server integrations use the OAuth 2.0 Client Credentials flow: your application requests an access token from your own tenant, then sends that token to the SIS APIs.

Flow overview

1. SIS gives you the SIS API application details for the target environment.
2. Create or select an application registration in your own Entra tenant.
3. Add the SIS API application permission to your app registration.
4. Grant administrator consent for that permission in your tenant.
5. Request a token from your tenant token endpoint using /.default.
6. Call the API endpoint with Authorization: Bearer <access-token>.

Authorization: Bearer <access-token>

Who owns what

There are two applications involved:

Application	Owned by	Purpose
Your client app registration	Your organization	The workload that asks Entra ID for tokens.
SIS API enterprise application	SIS, represented in your tenant after consent	The API resource your token is issued for.

The most common onboarding confusion is mixing these two IDs. Use your client app's client ID when requesting the token. Use the SIS API application ID URI in the token scope. Use the SIS API client ID only when adding or consenting to the SIS API resource in your tenant.

Create your app registration

In your Azure tenant, create an app registration for the system that will call SIS APIs.

Recommended setup:

• Use one app registration per integration or workload.
• Use a descriptive name that identifies your organization and system.
• Use the Accounts in this organizational directory only option unless your internal governance requires otherwise.
• Create a client secret or certificate credential for server-to-server authentication.
• Store credentials in a secure vault and rotate them according to your security policy.

You will need these values:

Value	Where to find it
Tenant ID	App registration overview, or Entra tenant overview
Client ID	App registration overview
Client secret or certificate	App registration certificates and secrets

Add SIS API to your tenant

SIS exposes API permissions through a multi-tenant application. Your tenant must have a service principal for that application before your app can request application permissions for it. In the Azure portal this service principal is shown under Enterprise applications.

First try the normal portal path:

1. Open Microsoft Entra ID.
2. Go to Enterprise applications.
3. Search for the SIS API application name provided during onboarding.
4. If you find it, open it and continue with admin consent.

If you cannot find the SIS API under Enterprise applications, it may not yet have been created in your tenant. A tenant administrator can force the consent flow by opening this URL:

https://login.microsoftonline.com/{SIS tenant ID}/adminconsent?client_id={SIS API client ID}

Your SIS contact person will provide both {SIS tenant ID} and {SIS API client ID} for the environment. Do not replace {SIS API client ID} with your own client app's ID.

After the administrator accepts the consent prompt, go back to Enterprise applications and search again. The SIS API should now appear as an enterprise application in your tenant.

Grant admin consent

Application permissions require administrator consent in your tenant. A tenant administrator must grant consent before your app can request usable access tokens for SIS APIs.

In your app registration:

1. Open API permissions.
2. Select Add a permission.
3. Choose the SIS API application.
4. Select Application permissions.
5. Select the role or permission value provided by SIS.
6. Select Grant admin consent for your tenant.

If the SIS API application is missing from the picker, use the admin consent URL in the previous section first. Then return to your app registration and add the permission.

If consent has not been granted, token requests may fail with an Entra ID consent error, or the token may not contain the required application role.

Token request

Use the Microsoft identity platform token endpoint for the configured tenant.

POST https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id=<client-id>
&client_secret=<client-secret>
&grant_type=client_credentials
&scope=<sis-api-application-id-uri>/.default

Use your own tenant ID in the token URL. Use your app registration's client ID and credential. The scope should be the SIS API application ID URI followed by /.default.

Common token request mistakes:

• Using the SIS API client ID as client_id. Use your own app registration's client ID.
• Using your app registration's application ID URI as scope. Use the SIS API application ID URI.
• Forgetting /.default at the end of the scope.
• Requesting a token before admin consent has been granted.

Validate the token

Before calling the API, verify that the access token:

• Has the expected audience for the SIS API.
• Was issued by your Azure tenant.
• Contains the required application role.
• Has not expired.

SIS APIs reject requests with missing, expired, or incorrectly scoped tokens.

Operational guidance

• Store client secrets or certificates in a secure vault.
• Prefer certificate credentials for production integrations where possible.
• Cache access tokens until shortly before expiry.
• Never send credentials directly to SIS API endpoints.