KAA Certificate (mtls) based authentication for inbound Rest API

[AshishKumaS0872]

Hi Guys,

We build some inbound rest endpoint inside ServiceNow instance(Internal Instance) & we want to access these rest endpoint using some application, postman, curl command and other ways.
I need few guidance how can we setup KAA Certificate (mtls) for my server & client .
I have gone through lot of exploration but haven't found any concrete solution for my use case.

Kindly provide your valuation suggestion.

[JoeD55]

I'm running into what looks like the same issue and wanted to add some detail in case it helps get this answered, since I haven't found any public documentation on KAA anywhere.

Setup:

1. Third-Party ID Token Flow, federating trust to Microsoft Entra ID as an external OIDC provider
2. Two Entra app registrations; a resource app representing this instance, and a caller app authenticating via certificate-based client credentials (no client secret)
3. Caller app has the resource app's App Role granted with admin consent.
4. OIDC Provider Configuration points at the tenant-specific v2.0 metadata URL
5. User Claim set to appid, mapped to a ServiceNow integration user (Identity Type: Machine) whose User ID equals the caller app's Client ID
6. Auth Scope restricted to Table API.

Error (fully reproducible):

Unable to get user based on the claim defined for oidc_provider_configuration with sys_id={sys_id}: no thrown error

TrustedIdpAccessTokenUserLoader reject: iss=null resource=null reason=kaa_wrapper_required
detail=3P IdP JWTs must be presented inside a KAA envelope; bare-bearer delivery is not accepted: no thrown error

What I've ruled out:

1. Stale token caching (reproduced across multiple fresh connections)
2. Values/configuration mismatch (Tenant ID, Client ID, Resource URI all verified against the Entra registration)
3. Certificate-specific issues (reproduced identically with two different valid certificates, including one generated fresh for this integration)
4. Any relevant System Property (searched sys_properties for "kaa," "certificate," "attestation"; no results)
5. Any hidden/unexposed field on the OIDC Provider Configuration, Auth Scope, or REST API Auth Scope mapping records via Form Layout.

ServiceNow's own official blog on the Third-Party ID Token Flow describes plain Authorization: Bearer <jwt> delivery with no mention of any envelope or mTLS requirement, which doesn't match what I'm seeing.

My client is a Power Automate (low-code integration platform) sending a standard bearer token. It has no ability to present a client TLS certificate at the connection level, so if KAA specifically requires mTLS (proof of key possession via the TLS handshake itself, not just a cert-signed JWT payload), that's a hard capability gap for this kind of client, not something I can configure around.

Questions:

1. What does "KAA envelope" actually require here?
2. Is this new/recent validation behavior?
3. Is there a supported way for a bearer-token-only OAuth client to satisfy it, or a way to disable this requirement?

Would appreciate any insight.