Identity Assertion JWT Authorization Grant (ID-JAG), draft-ietf-oauth-identity-assertion-authz-grant-06

In one line: a client uses OAuth Token Exchange to get a short-lived, IdP-signed grant (the ID-JAG) for a Resource Authorization Server that already trusts the same IdP for SSO, then redeems it with the JWT Bearer grant for an access token without sending the user through a consent redirect.

What this is

When one application needs a user's data at another application, it normally starts an interactive OAuth flow that the IdP both apps use for SSO never sees (Section 1). This draft defines Cross-App Access (XAA), where the shared IdP brokers that access instead. The client presents its Identity Assertion (an OpenID Connect ID Token or SAML 2.0 assertion) or, optionally, an IdP Refresh Token to the IdP's token endpoint using Token Exchange (RFC 8693). The IdP returns an Identity Assertion JWT Authorization Grant (ID-JAG): a JWT with typ oauth-id-jag+jwt whose audience is the Resource Authorization Server (Section 3). The client redeems it at the Resource Authorization Server as an RFC 7523 JWT bearer grant. The Resource Authorization Server stays the issuer of access tokens and applies its own local policy to what it grants (Section 1). The draft is a profile of the Identity Chaining draft and is a Standards Track WG document in the OAuth working group (datatracker states: Active, I-D Exists, WG Document).

How it works

sequenceDiagram
    participant C as Client
    participant I as IdP Authorization Server
    participant R as Resource Authorization Server
    participant S as Resource Server
    C->>I: User SSO (OpenID Connect or SAML)
    I-->>C: ID Token or SAML assertion, optional Refresh Token
    C->>I: Token Exchange (subject_token, audience, resource, scope, client authentication)
    I-->>C: ID-JAG (issued_token_type id-jag, token_type N_A)
    C->>R: JWT bearer grant with the ID-JAG as assertion
    R-->>C: Access token
    C->>S: API request with access token

1. The user signs in to the Client at the IdP using OpenID Connect or SAML; the Client gets an Identity Assertion and optionally a Refresh Token (Section 4.2).
2. The Client sends a Token Exchange request to the IdP with requested_token_type=urn:ietf:params:oauth:token-type:id-jag, exactly one audience (the Resource Authorization Server), a recommended resource, optional scope or authorization_details, and the subject token (Section 4.3).
3. The IdP MUST authenticate the Client, validate the subject token, check policy, and return a signed ID-JAG in the access_token field of the response (Sections 4.3.3 and 4.3.4).
4. The Client posts the ID-JAG to the Resource Authorization Server's token endpoint as urn:ietf:params:oauth:grant-type:jwt-bearer (or jwt-dpop for a DPoP-bound ID-JAG), normally authenticating with its registered credentials; a sender-constrained ID-JAG may be redeemed without client authentication (Section 4.4).
5. The Resource Authorization Server validates typ, iss, signature, aud, client_id, tenant, cnf, and the resource, scope and authorization details, and then issues an access token (Section 4.4.1).
6. The Client calls the Resource Server with the access token. The Resource Server trusts only the Resource Authorization Server, not the IdP (Section 2.1).

Use cases

• Enterprise SaaS-to-SaaS integration: a SaaS app obtains an access token to a third-party SaaS API for a user without an interactive consent flow, with the enterprise IdP deciding which client may reach which application (Appendix A.1).
• Customer identity (CIAM): a first-party customer application invokes third-party developer SaaS components for the signed-in customer, with the CIAM platform acting as the IdP (Appendix A.2).
• Email and calendaring clients: a client with no pre-registered OAuth client at the IdP or the Resource Authorization Server identifies itself with a Client ID Metadata Document and authenticates with a private key, for example using private_key_jwt (Appendix A.3).
• AI agent calling external tools: the agent discovers the tool's authorization server through Protected Resource Metadata, checks for the id-jag grant profile, tries the silent ID-JAG path first, and otherwise falls back to an interactive authorization code flow (Appendix A.4).
• SAML-based SSO deployments: a client that uses SAML for SSO swaps its assertion for an IdP Refresh Token, then uses that token as the subject token to get ID-JAGs (Section 4.5).

Why This Matters Now

• Trigger: the top OAuth WG deep-dive candidate after triage, whose note (in tracks/oauth-wg/data/normalized/candidates.json) cites broad normative changes. Comparing the texts shows that most of those changes (client authentication at the IdP, a single audience, mTLS binding, new metadata) landed in -05. -06 changed the IdP error code for a failed subject token.
• Source evidence: the announcement on the OAuth list says the diff looks big but mostly tightens wording based on feedback from many new implementations, and that the flow and overall design have not changed. It calls out the IdP authenticating the Client, a single audience, invalid_request replacing invalid_grant for failed subject tokens, key-bound ID-JAGs replacing client authentication at the Resource Authorization Server, mTLS as a second binding option, id_jag_signing_alg_values_supported, and a new Privacy Considerations section.
• Expected impact: implementers of the IdP side of Token Exchange need to re-check error handling and client authentication. Resource Authorization Server implementers need to re-check the client-authentication alternative, the cnf handling, tenant checks and resource governance checks. The draft expires on 4 May 2027 (Status of This Memo), and the author says remaining open issues are to be discussed at IETF 127.

What Changed

• Spec/document change summary: the -05 to -06 diff (https://author-tools.ietf.org/iddiff?url1=draft-ietf-oauth-identity-assertion-authz-grant-05&url2=draft-ietf-oauth-identity-assertion-authz-grant-06) shows two substantive edits. The IdP error for a subject token that fails validation changes from invalid_grant to invalid_request, "as required by Section 2.2.2 of RFC 8693", and the Client is told it can get a new subject token and retry (Section 4.3.4.3). The draft also explains why access_denied is used instead of invalid_target when the Client or End-User is not authorized for the target: so that the Client can tell a forbidden target from an unrecognized one. The rest of that diff is dates, version strings and Document History lines.
• The Document History in -06 lists a long set of items under -05. The -04 and -05 texts show that the IdP client-authentication rule with invalid_client and the single-audience rule (Section 4.3.3), mTLS binding (Section 9.11.2), id_jag_signing_alg_values_supported (Section 7.1) and Privacy Considerations (Section 10) are absent from -04 and present in -05. -06 only adds the missing history lines. -05 was posted on 30 October 2026, and -06 on 31 October 2026 with 80 pages (Datatracker history, linked under Sources). spec-notes.md attributes each change to its revision.
• Section 4.3.3 requires the IdP to reject a request without client authentication with invalid_client. Section 4.4 requires the Resource Authorization Server to reject a request with neither client authentication nor a sender-constrained ID-JAG with invalid_client.
• Section 3 makes RS256 mandatory to implement for both the IdP and the Resource Authorization Server, and says Resource Authorization Servers SHOULD also support ES256. Section 7.1 says that if id_jag_signing_alg_values_supported is present it MUST include RS256.
• Compatibility or migration concerns: an IdP that returns invalid_grant for a bad subject token is no longer conformant with -06 and clients that key retry logic on invalid_grant at the Token Exchange step may need to handle invalid_request. At the Resource Authorization Server, invalid_grant is still the code for ID-JAG validation failures (Section 4.4.3), so the same client must distinguish the two endpoints. The announcement asks implementers of the Token Exchange step to check their error handling. Deployments that rely on a client being unauthenticated at the IdP, or that send more than one audience, are no longer conformant.

Technical Analysis

• Threat model implications:
  • Subject tokens are high-value (Section 9.2): one subject token can be exchanged for ID-JAGs to many Resource Authorization Servers, so the draft says deployments should not rely on client authentication alone, should keep client keys in a separate protection domain, and should consider sender-constraining and rotating Refresh Tokens.
  • Metadata and discovery attacks (Sections 9.5 and 9.6): a client that skips the RFC 8414 issuer check, or the RFC 9728 resource check, can be steered to an attacker's authorization server, which then relays the ID-JAG and the client's credentials. The draft names the issuer check as the primary defence and lists three further mitigations: the resource value in the ID-JAG, the IdP governance check, and sender-constraining.
  • Token confusion (Section 4.3.3): the IdP must confirm the subject token is of the stated type and was issued for that purpose, reject access tokens, ID-JAGs and client assertions presented as Identity Assertions, and reject a typ that names another token type. Because ID Tokens have no explicit typ, the draft allows deployment-specific ways to identify them.
  • Audience binding: the Resource Authorization Server must check that aud is its own issuer (a string or a one-element array) and must check client_id against the authenticated client (Section 4.4.1).
  • Identity trust (Section 9.8): sub_id.issuer must never establish trust in the ID-JAG issuer, and a Resource Authorization Server that resolves users by email or aud_sub is relying on the issuer tenant's administrators.
  • Disclosure (Sections 9.9 and 10): the ID-JAG is visible to the Client, so a pairwise sub, sub_id or aud_sub is disclosed to it and can be linked across Resource Authorization Servers. Error descriptions SHOULD NOT reveal, for example, license status.
• Protocol flow implications:
  • Token Exchange response quirks: the grant is returned in access_token with token_type N_A (Section 4.3.4).
  • Resource handling: resource is a single string or a non-empty array of unique strings in the claim and is compared with Simple String Comparison (Sections 3.1 and 4.3). The IdP may grant a subset but must copy each granted identifier exactly as sent.
  • Refresh tokens at the Resource Authorization Server: the Resource Authorization Server SHOULD NOT return one, and clients may resubmit the ID-JAG until it expires unless the server limits exp or tracks jti (Section 4.4.4).
  • Sender constraining (Section 9.11): DPoP puts jkt in cnf and requires the jwt-dpop grant type; mTLS puts x5t#S256 in cnf. An IdP SHOULD NOT bind to both. Clients SHOULD inspect the ID-JAG for the expected cnf because the response does not say whether binding happened, which guards against silent downgrade.
  • Client authentication alternatives: the Resource Authorization Server SHOULD require client authentication, but a sender-constrained ID-JAG from an unauthenticated client may be accepted, and then the cnf proof takes the place of the client_id check (Sections 4.4, 4.4.1 and 9.1).
  • Tenancy (claims in Section 3, rules in Sections 6.1, 6.2 and 6.4, rejection in Section 4.4.1): two separate claims. tenant, defined by OpenID Enterprise, names the issuer's tenant; a multi-tenant issuer must include it, and the Resource Authorization Server must trust iss and tenant together. aud_tenant, registered by this draft, names the Resource Authorization Server's tenant, and aud + aud_tenant + aud_sub must be unique there. The Resource Authorization Server must reject the ID-JAG with invalid_grant if it cannot determine the recipient tenant unambiguously.
• Interop concerns:
  • Client ID mapping (Section 5.1): the IdP must know the client's identifier at the Resource Authorization Server by an out-of-band record, or clients can use Client ID Metadata Documents as a shared namespace.
  • Subject identifier mapping (Section 5.2): sub is chosen for the Resource Authorization Server, so it can differ from the sub in the Client's own ID Token. The same sub must be used for a given End-User and Resource Authorization Server regardless of which Client asks.
  • SAML NameID (Section 3.2): sub_id with format saml-nameid forbids transient NameIDs, requires comparing every member the Resource Authorization Server uses (including sp_name_qualifier), and does not cover deployments that resolve users by an attribute outside <Subject>.
  • Key discovery: the IdP SHOULD publish its signing key at jwks_uri in metadata located per RFC 8414, with an OpenID Discovery fallback allowed for the Resource Authorization Server (Section 7.1).
  • Dependencies on other drafts: the Identity Chaining draft (version 17 is cited) and the DPoP grant draft (version 02 is cited) are Work in Progress, so changes in them can affect this profile.

Open Questions

• Section 9.3 still contains a "TBD" about requesting the ID-JAG in the authorization request when stepping up authentication, to save a round trip. The draft says nothing on how insufficient_user_authentication interacts with the new invalid_request rule for the subject token.
• Section 4.3.3 and Section 9.10 leave actor_token and the act claim without normative processing, and say only that future extensions may define them. The draft does not say how a Resource Authorization Server should treat an act claim it receives.
• The announcement does not list the "remaining open issues" for IETF 127. Open issues in the working group repository cover resource handling (#141, #142), access token lifetime (#145), multi-tenancy (#109, #129), DPoP nonces (#106) and the gateway topology conflict with the Section 4.3.3 audience check (#114).
• Section 4.3.4.3 says an expired or revoked Refresh Token subject token yields invalid_request. This matches RFC 8693 Section 2.2.2, which requires invalid_request whenever a subject_token is invalid. RFC 6749 Section 5.2 uses invalid_grant for an invalid refresh token, but only in a refresh grant. Here the Refresh Token arrives as a Token Exchange subject_token, so RFC 8693 governs. A client that also refreshes tokens directly has to expect invalid_grant there and invalid_request at Token Exchange.
• Section 4.3.3 makes the IdP resource-governance check a SHOULD while Section 9.5 relies on that check as one defence. Section 4.3.3 also says how the IdP learns which resources a Resource Authorization Server governs is out of scope.
• Section 4.4.4 allows reuse of an ID-JAG for new access tokens but leaves one-time use to Resource Authorization Server policy via jti. The draft does not give a shared rule, so behaviour may differ between servers.
• Section 7.2 lets a Resource Authorization Server advertise authorization_grant_profiles_supported but Section 9.7 forbids it from disclosing issuer allow lists, so a client has no standard way to learn in advance whether a given issuer will be accepted beyond the optional protected discovery mechanism.
• Section 4.3.4.3 lists invalid_request, access_denied and invalid_target as profiled IdP codes, while Section 4.3.3 also requires invalid_client. Section 4.4.3 says it profiles "the following two codes" yet Sections 4.4 and 4.4.1 also use invalid_client. Whether a complete error table is wanted is unclear.

Experiments

• Lab 1: Stand up a test IdP token endpoint that accepts the ID-JAG Token Exchange and send it five bad requests, then compare the responses with what -06 specifies and with what existing libraries return: no client authentication (invalid_client, Section 4.3.3); two audience values (invalid_request, Section 4.3.3); an access token as subject_token (Section 4.3.3 forbids accepting it but names no code; invalid_request is inferred from Section 4.3.4.3, which profiles subject-token validation failures with it); an expired ID Token (invalid_request, Section 4.3.4.3); and an ID Token whose aud is a different client (invalid_request for an audience mismatch, Section 4.3.4.3).
• Lab 2: Take one valid ID-JAG and present it to a Resource Authorization Server with mutations that Section 4.4.1 says must fail with invalid_grant (Section 4.4.3): wrong typ, aud that does not identify this server, a client_id that does not match the authenticated client, a resource the server does not govern, a missing tenant from a multi-tenant issuer, and a cnf binding that does not verify. Then present an unmodified ID-JAG for an End-User the server does not entitle, and one whose resources are all rejected by local policy; both should return access_denied (Sections 4.4.1 and 4.4.3). Record any server that mixes up the two codes.
• Lab 3: Request a DPoP-bound and an mTLS-bound ID-JAG and redeem each at the Resource Authorization Server. With the matching key or certificate it succeeds, using the jwt-dpop grant type for DPoP (Sections 4.4 and 9.11.1.2.1). With a different key or certificate it fails with invalid_grant (Sections 9.11.1.2.1 and 9.11.2.2). With no DPoP proof or no client certificate it also fails with invalid_grant (Sections 9.11.1.2.2 and 9.11.2.2). Then redeem an unbound ID-JAG without client authentication: that is invalid_client, while a sender-constrained ID-JAG without client authentication may be accepted (Section 4.4).

Sources

• https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/06/
• https://mailarchive.ietf.org/arch/msg/oauth/-3eHjZkoYNz0qDpviERKkheVDbI/
• https://mailarchive.ietf.org/arch/msg/oauth/h4Zk-3zySe6CD3fuxoaHst4scH8/
• https://mailarchive.ietf.org/arch/msg/oauth/0cWcjyFw5Dg4iOH5Zf02P5sVTrg/
• https://github.com/oauth-wg/oauth-identity-assertion-authz-grant
• https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/issues
• https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/history/
• https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-04.txt
• https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-05.txt
• https://author-tools.ietf.org/iddiff?url1=draft-ietf-oauth-identity-assertion-authz-grant-05&url2=draft-ietf-oauth-identity-assertion-authz-grant-06
• https://www.rfc-editor.org/rfc/rfc8693#section-2.2.2
• https://www.rfc-editor.org/rfc/rfc6749#section-5.2

Trigger

The pipeline picked draft-ietf-oauth-identity-assertion-authz-grant at revision -06 (Datatracker states: Active, I-D Exists, WG Document) as the top OAuth WG candidate after triage. The triage note credits -06 with broad normative changes; comparing the -04, -05 and -06 texts shows most of them landed in -05, and -06 changed the subject-token error code. The OAuth list announcement from the author says the same changes are mostly clarifications from implementation feedback and that the flow and overall design are unchanged.

Why This Matters

ID-JAG, informally Cross-App Access (XAA), moves the decision to broker app-to-app API access to the IdP that both applications already use for SSO. The draft's own use cases include enterprise SaaS integrations, customer identity platforms, email and calendar clients, and AI agents calling external tools (Appendix A). Because the grant is redeemed without a user prompt, the security of the whole chain depends on correct client authentication, token typing, audience and resource checks, tenant handling and, optionally, sender constraining. Several of these rules were tightened in -05 and -06, so independent implementations are the ones most likely to differ. The authors say there are now many implementations across IdPs, authorization servers, clients and libraries.

Open Questions

• How should clients tell the two error endpoints apart in retry logic, given invalid_request at the IdP and invalid_grant at the Resource Authorization Server for expired inputs (Sections 4.3.4.3 and 4.4.3)?
• Which of the open issues in the working group repository (for example #141, #142, #145, #129 and #114, linked in README.md) the author will bring to IETF 127. The announcement does not say.
• Whether the draft's reliance on two Work in Progress drafts (Identity Chaining and the DPoP JWT grant) will cause changes here as they move.

References

Normative references listed in Section 12.1:

• Work in progress: draft-ietf-oauth-identity-chaining-17 (OAuth Identity and Authorization Chaining Across Domains) and draft-parecki-oauth-jwt-dpop-grant-02 (OAuth 2.0 JWT Authorization Grant with DPoP Binding).
• OAuth core and assertion framework: RFC 6749, RFC 7521, RFC 7523, RFC 8693 (Token Exchange), RFC 8707 (Resource Indicators), RFC 8414 (Authorization Server Metadata), RFC 9728 (Protected Resource Metadata, moved to normative in -05), RFC 7591 (Dynamic Client Registration).
• Tokens and keys: RFC 7518, RFC 7519, RFC 7638, RFC 7800, RFC 8725 (JWT BCP), RFC 9449 (DPoP), RFC 8705 (mutual TLS), RFC 9396 (Rich Authorization Requests), RFC 9493 (Subject Identifiers for Security Event Tokens).
• Other: RFC 2046, RFC 2119, RFC 3986, RFC 6838, RFC 8174, OASIS SAML Core 2.0, OpenID Connect Core 1.0, OpenID Connect Discovery 1.0, OpenID Connect Enterprise Extensions 1.0 draft 01, and the IANA registries for JWT, Media Types and OAuth Parameters.

Informative references listed in Section 12.2:

• draft-ietf-oauth-client-id-metadata-document-02, RFC 9068 (JWT Profile for OAuth 2.0 Access Tokens) and RFC 9470 (Step Up Authentication Challenge).

Key Changes

Changed in -06 (diff: https://author-tools.ietf.org/iddiff?url1=draft-ietf-oauth-identity-assertion-authz-grant-05&url2=draft-ietf-oauth-identity-assertion-authz-grant-06):

• IdP error for a subject token that fails validation changed from invalid_grant to invalid_request, citing RFC 8693 Section 2.2.2. A Client that gets invalid_request for a request that previously succeeded can get a new subject token and retry (Section 4.3.4.3).
• New explanation that access_denied is used instead of invalid_target when the Client or End-User is not authorized for the target, so the Client can distinguish a forbidden target from an unrecognized one (Section 4.3.4.3).
• Document History only: entries were added under -05 for changes whose text was already in the -05 body (listed below).
• Dates and version strings moved to 31 October 2026 and an expiry of 4 May 2027.

Introduced in -05 (absent from the -04 text, present in -05):

• Client authentication required at the IdP, with invalid_client (Section 4.3.3).
• A single audience value, invalid_target handling, resource comparison by Simple String Comparison, and resource RECOMMENDED in the Token Exchange request (Section 4.3.3).
• mTLS certificate binding alongside DPoP (Section 9.11.2).
• id_jag_signing_alg_values_supported metadata and RS256 mandatory to implement (Sections 3 and 7.1).
• Storage guidance for subject tokens (Section 9.2).
• Privacy Considerations (Section 10).

Already in -04 and extended in -05: the jwt-dpop grant type for DPoP-bound ID-JAGs, the saml-nameid Subject Identifier Format with more NameID rules in -05, and the email and calendaring example, which -05 ties to the Client ID Metadata Document.

Impact Analysis

• Upstream: the profile sits on RFC 8693 (Token Exchange), RFC 7523 (JWT bearer grant), OpenID Connect or SAML for the SSO assertion, RFC 8414 and RFC 9728 for discovery, RFC 9449 and RFC 8705 for sender constraining, and the Identity Chaining draft (cited at -17), which defines identity_chaining_requested_token_types_supported. Changes in those documents, particularly the two Work in Progress drafts, can change this one.
• Downstream: IdPs must implement the Token Exchange profile with mandatory client authentication, subject token typing, audience and resource policy, and the required error codes. Resource Authorization Servers must implement ID-JAG validation, tenant handling, resource and scope policy, and an optional sender-constraining path. Clients must register at both servers (or use Client ID Metadata Documents), validate discovery metadata, and manage subject token storage. IANA registrations requested: media type oauth-id-jag+jwt, token type URI urn:ietf:params:oauth:token-type:id-jag, grant profile URI urn:ietf:params:oauth:grant-profile:id-jag, metadata names authorization_grant_profiles_supported and id_jag_signing_alg_values_supported, JWT claims resource and aud_tenant, and the Subject Identifier Format saml-nameid.
• Compatibility: an IdP that returns invalid_grant for a bad subject token, accepts unauthenticated Token Exchange requests, or accepts several audiences is not conformant with -06. A Resource Authorization Server must reject a request that has neither client authentication nor a sender-constrained ID-JAG, and must reject an ID-JAG whose cnf method it does not support. The draft is still a working group draft, so wire details can change before publication.

• The IdP rejects a Token Exchange request with no client authentication using invalid_client (Section 4.3.3).
• The IdP rejects a request with more than one audience value using invalid_request, and rejects an audience it has no trust relationship with using invalid_target (Section 4.3.3).
• The IdP returns invalid_request, not invalid_grant, when the subject token is expired, malformed, has the wrong audience, or is an expired or revoked Refresh Token (Section 4.3.4.3).
• The IdP returns access_denied, not invalid_target, when the subject token is valid but the Client or End-User is not authorized for the target (Section 4.3.4.3).
• The IdP rejects an access token, an ID-JAG, a client assertion, or a SAML assertion issued for another purpose when presented as subject_token, and rejects a JWT whose typ identifies another token type (Section 4.3.3).
• For an Identity Assertion, the subject token audience (ID Token aud or SAML Audience) equals the client_id used for client authentication, and the SAML Audience is mapped to a Client ID (Sections 4.3.3 and 4.5).
• Granted resource values are copied exactly as the Client sent them, compared with Simple String Comparison, and invalid_target is returned if none are granted or a required resource is absent (Section 4.3.3).
• The Client puts the resource value from validated Protected Resource Metadata into the request unchanged, and has checked the RFC 8414 issuer and RFC 9728 resource values before sending anything (Sections 4.3, 9.5 and 9.6).
• The Token Exchange response has issued_token_type urn:ietf:params:oauth:token-type:id-jag, token_type N_A, the ID-JAG in access_token, and scope whenever it differs from the request (Section 4.3.4).
• The ID-JAG header typ is oauth-id-jag+jwt, the required claims iss, sub, aud, client_id, jti, exp and iat are present, RS256 is accepted, and an id_jag_signing_alg_values_supported list, if published, includes RS256 (Sections 3, 3.1 and 7.1).
• The Resource Authorization Server accepts aud as a string or a one-element array equal to its issuer, and rejects any other array or value with invalid_grant (Section 4.4.1).
• The Resource Authorization Server rejects with invalid_grant when the client_id claim does not identify the authenticated client, and when no client authenticates it requires a valid cnf proof (Section 4.4.1).
• The Resource Authorization Server rejects a request with neither client authentication nor a sender-constrained ID-JAG using invalid_client (Section 4.4).
• For a multi-tenant issuer the ID-JAG carries tenant, and the Resource Authorization Server rejects it with invalid_grant when the tenant is missing, untrusted for the pair of iss and tenant, or the recipient tenant is ambiguous (claim in Section 3; Sections 6.1 and 4.4.1).
• The Resource Authorization Server keeps aud_tenant, aud_sub and client_id consistent with its tenant model, and the same End-User always gets the same sub for a given Resource Authorization Server and aud_tenant regardless of Client (claim in Section 3; Sections 5.2, 6.2 and 6.3).
• Every identifier in the resource claim is governed by the Resource Authorization Server for the right tenant, or the request fails with invalid_grant, and the issued access token is restricted to those resources (Section 4.4.1).
• An ID-JAG with an unsupported cnf confirmation method, a cnf with no proof, or a thumbprint mismatch fails with invalid_grant for both jkt and x5t#S256 (Sections 9.11, 9.11.1.2 and 9.11.2.2).
• A DPoP-bound ID-JAG is redeemed with grant type urn:ietf:params:oauth:grant-type:jwt-dpop, and the Client checks that the returned ID-JAG has the cnf it asked for (Sections 4.4 and 9.11.1.1).
• When both a DPoP proof and a client certificate are presented on the Token Exchange request, the IdP binds the ID-JAG to only one mechanism (Section 9.11).
• SAML NameID sub_id never uses a transient NameID, includes sp_name_qualifier when the NameID is scoped to a Service Provider, is compared on every member the Resource Authorization Server uses, and the ID-JAG issuer is tied to the SAML issuer through local configuration rather than through sub_id.issuer (Sections 3.2.2 and 9.8).
• A Resource Authorization Server that requires a SAML NameID sub_id rejects an ID-JAG with no sub_id, a malformed sub_id, an unsupported format, or an unauthorized issuer using invalid_grant (Section 3.2.2).
• Client retry logic distinguishes invalid_request at the IdP from invalid_grant at the Resource Authorization Server. A new ID-JAG may resolve invalid_grant but will not resolve access_denied, so a client should not keep requesting new ID-JAGs after access_denied (Sections 4.3.4.3 and 4.4.3).
• A Resource Authorization Server that advertises urn:ietf:params:oauth:grant-profile:id-jag also lists urn:ietf:params:oauth:grant-type:jwt-bearer in grant_types_supported, and a client that advertises it lists both the token-exchange and jwt-bearer grant types (Sections 7.2 and 8).
• Error descriptions at both servers do not reveal whether the End-User holds a license or entitlement (Section 10).
• The IdP does not issue access tokens in response to an ID-JAG it issued itself unless explicitly configured, and the same ID-JAG is never used as a grant for a different downstream Resource Authorization Server (Section 9.4).

Environment

• Runtime:
• Tooling:
• Versions:

Steps

Results

Failure Modes

Next Actions