Delegated access: subject mapping and user approval #6887

Problem: When the gateway's authorization server redeems an ID-JAG or accepts a delegated token from another issuer, it cannot say which of its own users that is, or whether the user agreed to let that client use their connections. Today an ID-JAG's subject always becomes issuer#subject, and nothing records consent.

A valid mapping is not permission. Knowing that a source identity is local user U does not mean every client may use U's connections. Each client needs an approval, and only a redemption that passes both checks gets the delegated-access marker ("Add a delegated-access marker that gates credential lookup for approved delegated tokens", #6404).

Design home: a new resource-side companion RFC to THV-0079 (cross-app access). Mecatl's agent identity design describes the flow from the client side. Each item emits its audit events in the same change (#3919). Every denial records its reason: no mapping, no approval, reuse refused, or actor not allowed.

Which local user:

• A subject mode for each trusted issuer:

  • namespaced (the default);
  • matched through a shared login, with a configurable claim set (for example Entra tid + oid);
  • or through an approval record.

  In shared-login mode, refuse when two local users would resolve to the same company identity.

  One resolver serves both ID-JAG redemption and token exchange, and fails closed. Builds on PR Gate ID-JAG by issuer assertion types #6678. Per-issuer subject modes reverse the rule from closed Declare trust in external assertion issuers and map claims to authority #6337 "Declare trust in external assertion issuers and map claims to authority" that two issuers cannot resolve to the same local user.

• Redemption is allowed per issuer, client and resource, replacing the per-subject allowlist (subject_bindings, which must name every subject and allows no wildcard). The requested resource must equal the ID-JAG's resource claim (not checked today).

• Ordering: embedded-mode subject mapping and implicit approval (below) land before the marker (Add a delegated-access marker that gates credential lookup for approved delegated tokens #6404).

Approval:

• Approval record: local user, source issuer and subject, client, gateway, optional actor, source (user or administrator), time granted. It is checked at every redemption. Only the client it names can revoke it; revoking an approval with an actor constraint revokes it for that actor only. Redemption returns server_error when the store is unavailable.
• Embedded mode: when the gateway's authorization server signs users in through the client's own login, approval for a configured issuer, client and resource is implicit.
• Consent link: the redemption returns a pending approval plus an error_uri continuation, and the approval activates after a redirect and code exchange. The client must bind the callback browser to the user who started the flow; where it cannot, the screen names both accounts. Optionally, before activation, compare the approving user's company identity with the ID-JAG's subject when both come from the same IdP.
  • With open client registration this enables consent phishing by lookalike clients. Deployments that enable both need the registration gate (Gate inbound DCR (/oauth/register) behind an initial access token #6425), and the screen marks self-registered clients as unverified.
• The authorization server advertises support for the approval-continuation profile in its metadata. (Approval-continuation profile: invalid_grant with consent_required in error_description and an error_uri naming a pending approval the user can open; advertising it tells clients the error_uri is a consent link, not a help page.)
• Users can list and revoke their approvals. The consent screen takes the client's and actor's display names from the client registration and the trusted issuer configuration, never from the request.
• Administrator pre-approval, opt-in.

Policy for external issuers:

• Allowed actor issuers for each issuer and client. Effective actor: only the outermost act counts; if act has no iss, its issuer is the token's iss (Okta's act has none); if there is no act, there is no actor, and an approval that names an actor issuer does not match. The same rule applies to the approval record, to vMCP session binding (vMCP: bind sessions to the client, acting agent, and delegated-access marker, not just the user #6888) and to audit.
• ID-JAG reuse policy for each issuer: new issuers allow reuse until expiry; existing issuers keep single use.
• Foreign actor tokens: accept an actor_token issued by a configured external issuer, validated against that issuer's keys and the actor-issuer allowlist, not only tokens this server issued. Also accept JWT-SVIDs from a configured SPIFFE trust domain. Build one external-actor validator shared with the agent actor profile in Authorization server: refresh tokens and ID-JAG issuance for delegated agents #6886, since both replace the self-issued-only check in the token-exchange handler.
• A delegate allowed by wildcard or rule matching never gets the delegated-access marker; see Reduce delegate-client provisioning cost: TrustedIssuer actor matching and client-assertion auth #6321.

Conformance:

• ID-JAG redemption returns the granted resource, scope and authorization_details.
• An aud array must have exactly one element.

Sub-issues: #6321, #6892. Related: #6425 (needed before the consent link ships on a gateway that also allows open client registration).