ServiceNow, Azure AD and External Chatbot Integration for API execution

[vikashgohil]

Hello,

I have an external chatbot app on which the user logs in using SSO with Azure.

The ask is that this chatbot will create an RITM in Service Now, using the Service Catalog API, using the user's Role and ACLs. (On-behalf-of the logged in user).

Basically the Service Now API should get executed using the user's credentials in the same way as if the user is creating the request using front end.

The ask here is that user should not be asked to login again to Service Now for authenticating himself.

User will only login to chatbot with SSO using Azure.

I am not sure how we can implement this, I checked the approach of creating OAuth in System Registry, but it says chatbot should redirect user to service now authorization page, which I do not want.

I also checked for approaches for delegated user tokens and OAuth 2.0 OBO Pattern, but I am not sure what all things I need to configure on the Service Now side for these approaches.

If anyone has implemented this previously kindly provide guidance.

[Tanushree Maiti]

Hi @vikashgohil 

The integration works based on the permissions assigned to the integration user account. Once it’s set up, tickets can be created according to the access granted to that account, so end users don’t need to authenticate again.

One thing to clarify— is your ServiceNow instance integrated with Azure Active Directory SSO?

• If it’s not, then when an external chat user creates a request or incident, you’ll need to explicitly pass the caller/requested user (who exists in ServiceNow) in the request payload.

If no such user is available, you can default to the integration user. This helps ensure:

• The ticket source is properly identified
• Caller/requested fields are not left empty

Hope this helps clarify things.

[vikashgohil]

Hello Tanushree, I do not want to create a separate integration user. The integration from the chatbot should work as if the user himself is going to service now and raising an RITM from front end, except all this will happen in backend using APIs from the external app.

[RaghavendraGund]

If I understand correctly, You want token exchange — take the Azure AD token the user already has from chatbot login, and use it to authenticate to ServiceNow without another login prompt. This is the OAuth 2.0 On-Behalf-Of (OBO) pattern.

The Cleanest Approach would be: External OIDC Provider + OAuth
Here's what you need to configure on both sides:
ServiceNow Side Configuration
1. Register Azure AD as an External OIDC Provider
Go to System OAuth > OIDC Provider Configuration and create a new record:

OIDC Provider: Create new (name it something like "Azure AD")
OIDC Metadata URL: https://login.microsoftonline.com/{tenant-id}/.well-known/openid-configuration
Client ID: The Application (client) ID from your Azure app registration
Client Secret: The secret from Azure
Enable JTI Claim Verification: Usually false unless you need replay protection

2. Create an OAuth Application Registry for Inbound
Go to System OAuth > Application Registry → Create new:

Name: "Chatbot Integration" (or whatever)
Client type: External OIDC
OIDC Provider: Link to the one you created above
Grant type: You'll want "Authorization code" but here's the trick — for OBO, you actually need to configure it to accept JWT Bearer grants

3. Enable JWT Bearer Grant (This is the key part)
In the OAuth application registry, you need to enable the urn:ietf:params:oauth:grant-type:jwt-bearer grant type. This allows your chatbot to send the Azure AD token and exchange it for a ServiceNow token.
The flow becomes:
POST /oauth_token.do
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion={azure_ad_access_token}
client_id={your_servicenow_oauth_client_id}
client_secret={your_servicenow_oauth_client_secret}
4. User Mapping
ServiceNow needs to know how to map the Azure AD user to a ServiceNow user. Configure this in the OIDC Provider:

User field: Usually email or sub
User table field: Map to sys_user.email or sys_user.user_name

Make sure your ServiceNow users have matching email addresses or UPNs to what's in Azure AD.
Azure AD Side Configuration
1. App Registration for ServiceNow
If you haven't already, register ServiceNow as an app in Azure AD:

Go to Azure Portal > App Registrations
Create or find your ServiceNow app registration
Note the Application ID URI (you'll need this)

2. Expose an API Scope
In your ServiceNow app registration:

Go to "Expose an API"
Add a scope like user_impersonation or access_as_user

3. Grant Chatbot App Permission
In your chatbot's app registration:

Go to "API Permissions"
Add a permission → My APIs → Select your ServiceNow app
Add the scope you created
Grant admin consent

4. Configure OBO in Chatbot Code
Your chatbot backend needs to exchange tokens. Here's the rough flow in pseudocode:
javascript// Step 1: User logs into chatbot, you get their Azure token
const userAzureToken = "eyJ..."; // from chatbot auth

// Step 2: Exchange for ServiceNow token
const response = await fetch('https://your-instance.service-now.com/oauth_token.do', {
method: 'POST',
headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
body: new URLSearchParams({
grant_type: 'urn:ietf:params:oauth:grant-type:jwt-bearer',
assertion: userAzureToken,
client_id: 'your_sn_oauth_client_id',
client_secret: 'your_sn_oauth_client_secret'
})
});

const { access_token } = await response.json();

// Step 3: Call ServiceNow API with that token
const ritm = await fetch('https://your-instance.service-now.com/api/sn_sc/servicecatalog/items/{item_sys_id}/order_now', {
method: 'POST',
headers: {
'Authorization': `Bearer ${access_token}`,
'Content-Type': 'application/json'
},
body: JSON.stringify({ /* your catalog item variables */ })
});
Alternative: Direct JWT Validation (Simpler but Less Flexible)
If the JWT Bearer grant feels like overkill, you can configure ServiceNow to directly accept Azure AD tokens:

Go to System OAuth > Application Registry
Create a "JWT Verifier" type application
Point it to Azure AD's JWKS endpoint
Configure audience and issuer validation

Then your chatbot can just pass the Azure AD token directly in the Authorization: Bearer header. ServiceNow will validate it against Azure AD's public keys.
The downside: you're trusting the Azure token directly, so token lifetime and refresh becomes more complex.
Common Gotchas

User must exist in ServiceNow — The token exchange won't create users. Make sure Azure AD users are synced to ServiceNow (via LDAP, SCIM, or whatever you use).
Audience claim — The Azure token's aud claim must match what ServiceNow expects. If your chatbot gets a token for Microsoft Graph, it won't work for ServiceNow. You need to request a token specifically for ServiceNow's app registration.
ACLs will work — Once ServiceNow issues its own token based on the user identity, all role-based ACLs apply normally. The user's session is established just like a regular login.
Clock skew — Make sure your ServiceNow instance and Azure AD clocks are in sync, or you'll get token validation errors.