ServiceNow Zurich: OIDC workload identity federation with Microsoft Entra ID without client secrets

[rpinto]

Hi everyone,

We want a ServiceNow Zurich server-side script, triggered by a Service Portal widget, to authenticate to a Microsoft Entra app registration using workload identity federation, similar to GitLab CI/CD OIDC job tokens.

The intended flow is:

1. ServiceNow issues a short-lived, signed token representing a dedicated application/workload identity.

2. The server script exchanges it at Entra’s token endpoint using a federated identity credential.

3. The resulting application access token is used to call an external API.

Our instance exposes /.well-known/openid-configuration, including an issuer and a jwks_uri pointing to oauth_jwks.do.

Has anyone implemented this directly from ServiceNow, without a client secret or customer-managed signing certificate/key?

Specifically:

• Is there a supported API for issuing an application identity JWT using ServiceNow-managed, automatically rotated signing keys?

• Can we configure its sub and aud claims and have its signature verified through the instance’s published JWKS?

• If available, which Zurich patch, plugins and configuration are required?

We are looking for outbound application authentication, independent of the logged-in user. We have found examples of inbound OIDC validation, user SSO and GlideJWTAPI with a configured signing key, but those do not establish this particular capability.

A working example, documentation reference or confirmation of a platform limitation would be very helpful.

Thanks,
Rodrigo

[kmohammed]

Hi Rodrigo,

Short answer: no, not as a supported capability in Zurich. ServiceNow does not offer a GitLab-style workload token issuer — there is no supported API to mint a short-lived application JWT with a configurable sub and aud using ServiceNow-managed, automatically rotated keys, and no Zurich patch or plugin enables it.

The /.well-known/openid-configuration and JWKS endpoint you found are for ServiceNow acting as an OIDC identity provider for inbound user authentication (ID tokens for signed-in users), not for issuing workload tokens. GlideJWTAPI is the opposite direction: you supply the signing key or certificate, so it does not meet your "no customer-managed key" condition.

The closest supported secretless pattern is certificate-based client credentials in Entra: register the application, upload a certificate, and configure OAuth 2.0 / JWT-bearer authentication in a REST Message or IntegrationHub credential. That proves possession of a certificate instead of a shared secret, and uses no client secret — but the certificate is still customer-managed.

If you genuinely need a federated token, broker it outside ServiceNow: a small service with an Azure managed identity (for example on the MID Server host or an Azure Function) can hold the federated identity, ServiceNow calls it with its own authenticated request, and the broker exchanges that for an Entra access token. I would not build a production flow on minting tokens with GlideJWTAPI and a self-managed key and call it workload federation, nor try to reuse a logged-in user's SSO token for user-independent application calls.

If anyone has found a supported Zurich add-on for this, I would be glad to hear about it — but as far as I can establish, this is a platform limitation, not a missing configuration.

If this helped, please mark it as Helpful — and if it solved your issue, I'd be grateful if you accepted it as the solution.