ID-JAG

Identity Assertion JWT Authorization Grant. This is the token form used after SSO so the client can exchange an identity assertion for a server-specific access token. It is useful because the policy decision happens at issuance time, but it still needs downstream controls to make actions safe.

Expanded Definition

ID-JAG, or Identity Assertion JWT Authorization Grant, is a token exchange pattern used after SSO when a client presents an identity assertion and receives a server-specific access token. In practical NHI and IAM designs, it separates authentication context from authorisation context, so the original assertion is not reused as the final credential for downstream actions.

This distinction matters because the issued JWT can carry audience, scope, expiry, and other constraints that are tailored to the target service. That makes ID-JAG useful for reducing token reuse across systems, but it does not remove the need for service-side checks such as scope validation, token lifetime limits, and policy enforcement at the resource server. Guidance varies across vendors on naming and exact flow boundaries, so teams should treat the pattern as an implementation approach rather than a universal standard.

The most common misapplication is treating the assertion token itself as the runtime authorisation token, which occurs when teams skip exchange and forward the SSO artifact directly to downstream APIs.

Examples and Use Cases

Implementing ID-JAG rigorously often introduces an extra token exchange step, which adds latency and integration complexity in exchange for tighter audience restriction and better credential containment.

• A service receives a user or workload assertion after SSO and exchanges it for a short-lived token scoped only to one API.
• An internal platform uses the exchange to issue different access tokens for read-only and write operations, reducing overbroad reuse.
• A gateway validates the incoming assertion once, then mints a downstream token with a narrower audience for microservice calls.
• Teams compare the flow against broader identity governance guidance in the Ultimate Guide to NHIs while using the NIST Cybersecurity Framework 2.0 to map control expectations around token handling and access enforcement.
• A job runner uses the exchanged token for a single bounded task instead of reusing a long-lived assertion across the workflow.

In environments where identity sprawl is already high, Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x, which makes token exchange patterns attractive for limiting blast radius.

Why It Matters in NHI Security

ID-JAG is important because it helps convert a broad identity assertion into a purpose-bound access token, which supports least privilege at issuance time. That is especially valuable in NHI architectures where service accounts, agents, and automated jobs often operate at machine speed and can amplify mistakes quickly. NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, a reminder that issuance-time controls alone are not enough if downstream scopes remain too broad.

Practitioners should understand that the security value of ID-JAG depends on what happens after token issuance. Resource servers still need to validate audience, expiration, and entitlement, and governance teams still need visibility into who can mint tokens and for what services. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces access control, monitoring, and continuous risk management rather than relying on a single authentication event.

Organisations typically encounter misuse of this pattern only after a token is replayed across services or a downstream API is overexposed, at which point ID-JAG becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• ID-JAG Token
• How should security teams implement Client ID Metadata Documents?
• How should teams govern hybrid Active Directory and Entra ID at the same time?
• How should security teams govern synchronized Entra ID accounts?