ndovuagent-auth

NDOVU · AGENT AUTH · ID-JAG

Agent auth: ID-JAGs, rule by rule

An open lab-site on Identity Assertion JWT Authorization Grants: validate a grant rule by rule against draft -05, mint deliberately broken ones from a stub enterprise IdP, and check authorization-server metadata coupling - all in your browser.

updated October 31, 2026draft -05 · October 30, 2026

Applications at one enterprise sign in through a common identity provider. When one of them needs to call another application's API on the user's behalf, Cross-App Access (XAA) routes that delegation through the same IdP instead of building a new app-to-app trust path: the IdP vouches for the user with a short-livedIdentity Assertion JWT Authorization Grant (ID-JAG), and the destination's authorization server decides whether to honor it. The draft is short and the rules are load-bearing; this lab-site validates them rule by rule and explains the machinery behind them. Start anywhere:

Validator

Paste a token, mint a broken one, or check metadata - a rule-by-rule console over the id-jag-validate engine. Runs in the page.

Rules explorer

Both draft revisions, every rule grouped by section cite, with the -04 to -05 delta computed from the rule data.

Guide

How XAA works: the roles, the two hops, the wire shapes, and the attack/defense map - with a citation on every mechanic.

Primer

The draft itself: status and history, the claims table, metadata parameters, the revision timeline, and the keyword map.

The flow on one screen

Four parties, two hops, one grant. Solid arrows carry requests, dashed arrows carry responses (Section 4.1).

ClientIdP ASResource ASResource Server1 · user SSO (OIDC or SAML)ID Token (+ optional refresh token)2 · token exchange (RFC 8693)requested_token_type=id-jagaudience=<RAS issuer> · subject_token=<ID Token>ID-JAG (token_type=N_A)3 · jwt-bearer grant (RFC 7523)grant_type=jwt-bearer · assertion=<ID-JAG>access token (+ granted scope)4 · API callAuthorization: Bearer <access token>
  1. User SSO. The client signs the user in with the IdP and receives an Identity Assertion: an OpenID Connect ID Token or a SAML 2.0 assertion, plus an optional refresh token (Section 4.2).
  2. Token exchange. The client trades the assertion at the IdP's token endpoint for an ID-JAG: a Token Exchange request with requested_token_type=urn:ietf:params:oauth:token-type:id-jag and audience set to the Resource Authorization Server's issuer (Section 4.3).
  3. jwt-bearer grant. The client presents the ID-JAG to the Resource Authorization Server as a JWT bearer assertion (RFC 7523) and gets back an access token (Section 4.4).
  4. API call. The client calls the Resource Server with the access token. Note what never happened: the IdP never held or issued an access token for the chat API - the Resource Authorization Server minted this one (Section 1).

The four roles

RoleWho that isCite
Clientthe app the user signed into and that wants to call another app’s API - the wiki app in the draft’s exampleSection 2.1
IdP Authorization Serverthe identity provider both sides already trust for SSO and subject resolution; it mints the ID-JAGSection 2.1
Resource Authorization Serverthe other app’s authorization server; it validates the ID-JAG and issues its own access tokensSection 2.1
Resource Serverhosts the API itself; it never sees the IdP, only access tokens from its own authorization serverSection 2.1

The trust is asymmetric and already paid for: the client has a SSO relationship with the IdP, the Resource Authorization Server independently trusts that same IdP for SSO and subject resolution, and the Resource Server trusts only its own authorization server (Section 5). XAA adds no new trust relationships; it reuses the federation that exists.

Three tracks, one site

Identity delegation

One app acts for a user at another app’s API, brokered by the IdP both already trust for SSO. This is Cross-App Access, realized with the ID-JAG draft - this site’s subject.

start with how XAA works →
Web Bot Auth

Automated clients proving who they are at the HTTP layer, so servers can tell good bots from bad ones. An adjacent track; not covered on this site yet.

not covered on this site yet
Agents as identity subjects

Agents holding identity of their own, distinct from the user they act for: delegation chains, actor claims, agent-scoped credentials. An adjacent track; not covered on this site yet.

not covered on this site yet

Pick your seat

IdP admin

You mint the grants. See exactly what an ID-JAG looks like on the wire, then break one on purpose, a rule family at a time.

Open the Mint tab

read how the exchange works

RAS implementer

You validate the grant and issue the access token. Walk the processing rules with your own deployment context supplied.

Open the Validate tab

browse the rules by section

MCP server developer

Your server is the resource side. Check the metadata advertisement and the grant-type coupling an authorization server must carry.

Open the Metadata tab

see the metadata rules

Client developer

You run the two hops: token exchange at the IdP, then the jwt-bearer grant at the resource side. Read both on the wire first.

Read how XAA works

mint a grant to see its shape

Auditor

You need the paper trail: draft status and history, the full claims table, and which normative keyword carries which weight.

Read the draft primer

trace every rule to its section

References

Normative - the documents the pattern is built from:

Informative - status and context: