ID-JAG, The OAuth Glue between Agents and Resource servers

Why OCI Identity Domains ID-JAG Tokens Matter for Cross-Domain Access

Modern workloads running on OCI or elsewhere rarely consist of a single application, a single API, or even a single identity boundary. An employee may authenticate once with an OCI Identity Domain, then use an Oracle-hosted application, automation, or AI agent that needs access to an MCP server, a tool, or an API protected by a different trust domain.

The challenge is to enable that access without repeatedly redirecting the user for consent, passing a raw ID token to an unrelated resource server, or creating broadly trusted, long-lived credentials.

OCI Identity Domains supports this pattern with an Identity Assertion JWT Authorization Grant, or ID-JAG. An ID-JAG is a short-lived, signed JWT that carries an authorization assertion across trust domains. It is not an OAuth access token and must not be used to call an API directly. Instead, it is redeemed by a target Identity Domain for an access token that the target resource server accepts. Oracle documentation

The value of ID-JAG

ID-JAG separates three concerns that should remain independent:

• Authentication: a user signs in through the source OCI Identity Domain, or through enterprise federation that results in a source-domain-issued ID token.
• Cross-domain authorization handoff: the source domain evaluates its policy and issues an ID-JAG containing only approved identity and authorization context.
• Resource authorization: the target domain, which governs the resource server, validates the ID-JAG and independently issues its own OAuth access token.

This model gives administrators clear controls at both ends of the exchange. The source controls which runtime clients can mint ID-JAGs and which scopes and resources they may carry. The target controls which issuers, users, source clients, and target clients it accepts before issuing an access token. 

• OCI source-domain guidance
• OCI target-domain guidance

The result is useful for Oracle application-to-application access, automation, and agent scenarios where policy should be decided in advance by the enterprise instead of through repeated browser redirects and consent prompts.

This provides several practical benefits:

• Centralized policy: Administrators govern which OAuth clients, scopes, resources, and trust relationships are allowed before runtime.
• Least privilege: The exchange request names the intended scope and resource instead of granting blanket access.
• No raw ID-token reuse: A source-domain ID token remains an identity artifact; it is exchanged for a purpose-built, short-lived assertion.
• Independent target authorization: The target domain does not automatically trust every assertion. It validates the ID-JAG against its configured inbound trust before issuing its own access token.
• Better support for automation: An Oracle-hosted application or agent can obtain delegated access through preconfigured policy rather than prompting the user during every cross-domain operation.

In short, the ID-JAG is the handoff artifact between identity domains. The resulting OAuth access token not the ID-JAG is what an application presents to the protected API (Resource Server). 

The request flow for ID-JAG

Prerequisites

Assuming OCI Identity domain is both the Enterprise IDP (source identity domain) and resource authorization server (target identity domain), follow steps below to setup the trust.

• Enable ID-JAG support in the source and target OCI Identity Domains.
• Create a confidential OAuth client in the source domain for the ID-token-to-ID-JAG exchange.
• Create a separate confidential OAuth client in the target domain for ID-JAG redemption. 
• Configure an active outbound Identity Propagation Trust (IPT) in the source domain.
• Configure an active inbound IPT in the target domain.
• Ensure that the source ID token has a nonempty `sub` claim and is issued by the source OCI Identity Domain. A raw upstream ID token, arbitrary JWT, or access token is not a substitute. 

Keep runtime-client credentials in a secret manager. The client that administers trusts should be separate from lower-privilege runtime exchange clients.

Configure the source outbound Identity Propagation Trust

The source Identity Propagation Trust is evaluated after the source domain validates the input ID token and authenticates the source runtime client, but before it creates the ID-JAG.

Its job is to answer: May this source client obtain an ID-JAG for this user, scope, and the target resource?

Important outbound settings include:

• `issuer`: exactly matches the `iss` claim of the submitted source-domain ID token.
• `active`: must be `true`.
• `idJagEnabled`: must be enabled for ID-JAG issuance.
• `idJagClients.idJagOauthClientIds`: source confidential runtime client IDs allowed to request an ID-JAG.
• `outboundIdJagPermittedScopes`: exact allowed scopes.
• `outboundIdJagPermittedResources`: exact allowed resource identifiers.

An illustrative outbound Identity Propagation Trust request body is shown below. Use the OCI Identity Domain SCIM APIs and your domain-specific administrative authorization to create it.

{
  "schemas": [
    "urn:ietf:params:scim:schemas:oracle:idcs:IdentityPropagationTrust"
  ],
  "name": "Source-to-target ID-JAG issuance",
  "description": "Allows the source runtime client to request a constrained ID-JAG",
  "type": "JWT",
  "issuer": "https://source-domain.identity.oraclecloud.com/",
  "active": true,
  "subjectClaimName": "sub",
  "subjectMappingAttribute": "userName",
  "idJagEnabled": true,
  "idJagClients": [
    {
      "idJagOauthClientIds": ["SOURCE_RUNTIME_CLIENT_ID"],
      "outboundIdJagPermittedScopes": [
        "https://resource.example.oraclecloud.com/read"
      ],
      "outboundIdJagPermittedResources": [
        "https://resource.example.oraclecloud.com/"
      ]
    }
  ]
}

The source domain intersects the requested values with the trust allow-lists. The trust limits what can leave the source domain; it does not decide whether the target will issue an access token.

Exchange a source ID token for an ID-JAG

After the user authenticates, use the source-domain-issued ID token in an RFC 8693 request to the source Identity Domain token endpoint. How the agent or user secures an ID token from the source identity domain is not in-scope for this blog. 

curl --request POST "$SOURCE_IDENTITY_DOMAIN/oauth2/v1/token" \
  --header "Authorization: BASIC $SOURCE_CLIENT_ID:$SOURCE_CLIENT_SECRET" \
  --header "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
  --data-urlencode "requested_token_type=urn:ietf:params:oauth:token-type:id-jag" \
  --data-urlencode "subject_token=$SOURCE_ID_TOKEN" \
  --data-urlencode "subject_token_type=urn:ietf:params:oauth:token-type:id_token" \
  --data-urlencode "scope=https://resource.example.oraclecloud.com/read" \
  --data-urlencode "resource=https://resource.example.oraclecloud.com/"

The source domain validates the client, the ID token, the matching outbound IPT, and the requested scope and resource. A successful response returns the ID-JAG in the `access_token` response member. Treat that value as an ID-JAG intermediate grant, not as a resource-server bearer token. 

Configure the target inbound Identity Propagation Trust

The target Identity Propagation Trust is evaluated when the application presents the ID-JAG to the target token endpoint.

Its job is to answer: Do we trust this source-issued assertion, can we resolve its subject locally, and may this target client redeem it?

Important inbound settings include:

• `issuer`: exactly matches the ID-JAG `iss` claim from the source domain.
• `active`: must be `true`; exactly one active inbound trust should match the issuer.
• `publicCertificate` or `publicKeyEndpoint`: provides the source signing key material used to verify the ID-JAG.
• `subjectClaimName`: normally `sub`.
• `subjectMappingAttribute`: the target-domain user attribute used to find exactly one active user, commonly `userName`.
• `idJagClients.inboundIdJagCrossDomainClientId`: source client IDs accepted from the ID-JAG `client_id` claim.
• `idJagClients.idJagOauthClientIds`: target confidential clients that are allowed to redeem the assertion.

The source client and target exchange client are different identities with different roles. They are evaluated together within the same `idJagClients` entry.

{
  "schemas": [
    "urn:ietf:params:scim:schemas:oracle:idcs:IdentityPropagationTrust"
  ],
  "name": "Accept source-domain ID-JAG",
  "description": "Allows the target runtime client to redeem approved source ID-JAGs",
  "type": "JWT",
  "issuer": "https://source-domain.identity.oraclecloud.com/",
  "active": true,
  "subjectClaimName": "sub",
  "subjectMappingAttribute": "userName",
  "publicCertificate": "BASE64_X509_SOURCE_SIGNING_CERTIFICATE",
  "idJagEnabled": true,
  "idJagClients": [
    {
      "idJagOauthClientIds": ["TARGET_RUNTIME_CLIENT_ID"],
      "inboundIdJagCrossDomainClientId": ["SOURCE_RUNTIME_CLIENT_ID"]
    }
  ]
}

Alternatively, configure a supported `publicKeyEndpoint` for source signing-key discovery. When that approach is used, the ID-JAG header must identify a verification key, such as with `kid`, `x5t`, or `x5t#S256`.

Exchange the ID-JAG for a target OAuth access token

The application now calls the target Identity Domain token endpoint. The target validates the ID-JAG signature and expiration, selects the inbound trust from the issuer, maps the subject, validates the source-to-target client binding, and applies its authorization policy.

curl --request POST "$TARGET_IDENTITY_DOMAIN/oauth2/v1/token" \
  --header "Authorization: Basic $TARGET_CLIENT_ID:$TARGET_CLIENT_SECRET" \
  --header "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer" \
  --data-urlencode "assertion=$ID_JAG" \
  --data-urlencode "scope=https://resource.example.oraclecloud.com/read"

The resulting `access_token` is an OAuth bearer token issued by the target Identity Domain. It is the only token in this flow that should be sent to the resource server.

Authorization: Bearer <target-domain-access-token>

The target resource server evaluates this access token according to its own authorization model and granted scopes. The ID-JAG itself is never an API credential.

This distinction is essential:

• The ID token identifies the authenticated user to the source side.
• The ID-JAG carries a short-lived, signed cross-domain authorization assertion.
• The OAuth access token is issued by the resource server’s Authorization Server and authorizes calls to that resource server.

The target domain remains in control: it independently decides whether to redeem the ID-JAG and what access token and scopes to issue. Oracle’s ID-JAG overview and target-domain redemption guidance describe this separation.

Operational guidance

If the Enterprise IDP and resource server authorization server is same then you can use two legged or three legged OAuth instead of using ID-JAG tokens.

• Require HTTPS for both token endpoints.
• Use confidential OAuth clients for both runtime exchanges.
• Store client secrets and tokens only in approved secret-handling systems.
• Configure exact issuer strings, including their trailing-slash behavior.
• Keep source scope/resource allow-lists narrow.
• Ensure the target subject mapping resolves to one active target-domain user.
• Bind the approved source client and target redemption client in the same inbound `idJagClients` entry.
• Do not log ID tokens, ID-JAGs, client secrets, authorization codes, or access tokens.
• Call the resource server only with the target-issued OAuth bearer access token.

OCI Identity Domains ID-JAG support gives Oracle environments a practical way to support governed, delegated access across trust boundaries. It moves authorization from repeated user interaction into explicit Identity Domain policy, while preserving independent control at the target domain.

Closing perspective

OCI Identity Domains ID-JAG support provides a governed handoff between domains: the source domain controls what assertion it will issue, while the target domain controls whether that assertion becomes access to a protected Oracle resource. The two-step exchange preserves trust boundaries, limits delegated authority, and gives the resource side the final authorization decision.

References 

• Oracle Documentation
• PM blog