Recently, I worked with a client that wanted to modernize how ServiceNow integrations were authenticated. Over time, multiple interfaces had been implemented using a mixture of local service accounts and integration-specific credentials. Each interface worked, but the overall model was becoming harder to govern and support.
The goal was to utilize a reusable authentication pattern that could support systems calling ServiceNow as well as ServiceNow calling external APIs. The client has settled on Microsoft Entra ID as the trusted identity provider and OAuth 2.0 as the common authentication mechanism.
The Challenge
Authentication is often treated as a setup activity rather than part of the integration architecture. That approach works until the number of interfaces grows and teams find themselves managing many accounts, secrets, tokens, and access paths.
For this implementation, we wanted a model that would:
- Centralize application authentication in Microsoft Entra ID
- Reduce reliance on passwords and locally managed integration credentials
- Support both inbound and outbound REST integrations
- Provide traceability through dedicated application identities
- Limit each integration to the ServiceNow APIs and roles it actually required
The Solution Architecture
Entra ID authenticates. ServiceNow authorizes. |
For inbound traffic, the calling application obtains an access token from Entra ID and presents that token to ServiceNow. ServiceNow validates the token, maps the application identity to a ServiceNow user, and then applies platform roles and OAuth scopes.
For outbound traffic, ServiceNow uses an OAuth Application Registry and OAuth profile to obtain an access token from Entra ID. REST Messages and Flow Designer actions reuse that configuration instead of managing token logic themselves.
Authentication patterns
Direction | Token requester | Identity provider | API client | Authorization point |
Inbound | External application | Microsoft Entra ID | ServiceNow API | ServiceNow scopes and roles |
Outbound | ServiceNow | Microsoft Entra ID | External REST API | External API permissions |
Securing Inbound REST Integrations
Inbound integrations presented the more interesting design problem. ServiceNow needed to trust tokens issued by Entra ID, identify the calling application, and then apply the correct ServiceNow permissions without relying on a shared username and password.
1. Configure the Entra OIDC provider
We started with an OAuth OIDC Provider configuration in ServiceNow. This record establishes the trust relationship used to validate incoming tokens issued by Entra ID.
Figure 1. OAuth provider record used for inbound Entra authentication.
The lower portion of the record contains the OIDC metadata URL and claim-mapping configuration.
Figure 2. OIDC metadata and user-claim configuration.
2. Map the application identity
The access token for my client includes an “azp” claim that identifies the authorized application. We mapped that claim attribute to a dedicated unique-ID field on the ServiceNow user record. This allowed each integration application to resolve to a controlled ServiceNow identity.
Figure 3. Claim mapping from azp to the ServiceNow unique-ID field.
A corresponding ServiceNow user record contains the Entra application identifier in the unique-ID field. With that association in place, ServiceNow can resolve the token to the intended non-interactive integration identity.
Figure 4. Integration user matched through the unique-ID field.
3. Apply least-privilege authorization
Authentication alone should not provide broad API access. We used an explicit authorization scope to limit the provider to the APIs approved for the integration.
Figure 5. OAuth authorization scope limited to approved APIs.
The mapped user was then assigned the ServiceNow roles required to load and process the inbound data. The exact roles will vary by interface, but the design principle remains the same: use a dedicated identity and grant only the access required for that integration.
Figure 6. Roles assigned to the inbound integration user.
Securing Outbound REST Integrations
Outbound integrations reverse the direction of trust. ServiceNow becomes the OAuth client and requests an access token that can be used when calling an external API.
1. Configure the OAuth Application Registry
We used an OAuth Application Registry record to store the client configuration and token endpoint needed to authenticate through Entra ID. The registry record becomes the reusable foundation for outbound integrations that use the same application registration and security model.
Figure 7. OAuth Application Registry configured for Entra ID.
The redirect URL must be reviewed as the configuration moves between ServiceNow environments. The token URL can remain associated with the same Entra tenant where that is part of the client's identity design.
2. Associate the OAuth profile with a REST Message
The REST Message references the OAuth 2.0 profile. At runtime, ServiceNow uses the profile to obtain the token and include it with the outbound request. This keeps authentication configuration out of individual scripts and Flow Designer actions.
Figure 8. REST Message authentication configured to use an OAuth profile.
Once the REST Message is configured, Flow Designer actions can invoke its HTTP methods without implementing a separate token-generation process. The action focuses on inputs, request content, and response handling while the REST Message manages authentication.
Why This Pattern Worked
A common identity layer: Both inbound and outbound interfaces use Entra ID, which reduces the number of authentication patterns the support team must understand.
Clear separation of responsibilities: Entra ID establishes application identity. ServiceNow controls platform access through claim mapping, OAuth scopes, users, and roles.
Reusable configuration: Provider, registry, profile, REST Message, and Flow Designer records can be reused as building blocks rather than recreated as custom token logic for every integration.
Better auditability: Dedicated application identities make it easier to distinguish one integration from another than a shared generic account.
Reduced credential handling: OAuth centralizes token issuance and minimizes the need to place authentication logic directly in scripts or individual flows.
Final Thoughts
What began as an authentication requirement became a reusable integration pattern. By using Microsoft Entra ID for application authentication and ServiceNow for platform authorization, we created a consistent approach for both inbound and outbound REST web services.
For teams building a growing ServiceNow integration portfolio, establishing a standard Entra and OAuth pattern early can prevent every new interface from becoming a separate authentication design exercise.
