Running several apps at once

Get a code for app A from scenario 16 (authorize) or 17 (hand-off) first — each redemption needs the verifier that matches the challenge THAT request carried. A receives its own access token (azp = A's client) and its own refresh credential. ONE redemption path for both acquisition routes — the authorize redirect (16) and the hand-off (17) mint the same row, differing only in issued_via. code_verifier is auto-filled from whichever card generated the challenge. The order of checks is part of the contract: client_id, redirect_uri and the verifier are validated BEFORE used_at, because rejecting a spent code first would answer before knowing whether the replay was otherwise valid. Replay = burn always, revoke conditionally: any second use is 400 invalid_grant and the code stays spent, but only a replay with ALL bindings valid also revokes the chain that code issued — a wrong verifier revokes nothing, else an attacker holding an intercepted but unusable code could log the victim out at will. The refresh credential arrives on the client's ONE registered channel (rt_<client_id> cookie, or refreshToken in the body) — never both, never the caller's choice. 404 when MULTI_APP_ENABLED is off.

Entering a second app is NOT a second authentication: no session is created, auth_time is carried forward, and no device challenge (scenario 11) is reachable from this path — otherwise the step-up clock would restart every time a user changed tabs. A second chain opens under the SAME session and A's stays live. Re-entering an app RETIRES its incumbent chain rather than opening a second: exactly one live chain per (session, client) is permitted, and the holder of the old credential is the same browser that was just handed a fresh one. CORS granularity differs by what a preflight can identify: this endpoint carries the client id in the BODY, so its allow-list is registry-wide across body clients and the per-client binding is enforced at the endpoint instead — by the code binding and PKCE, which no origin can influence. Contrast the CODE replay rule here (any second use is 400 invalid_grant and the code stays spent, but only a replay with ALL bindings valid also revokes the chain) with the session-wide reuse rule on the rotation route.

The chain is keyed (tenant, session, client), so rotating here cannot invalidate another app open under the same session — that isolation is what lets two products stay open in two tabs. Cookie clients send {} and the rt_<client_id> cookie rides along; body clients put { refreshToken } in the body. Reuse detection nonetheless stays SESSION-WIDE: a genuinely replayed token revokes every app. Per-chain isolation removed the false positives, not the policy. Two tabs of the SAME app share one chain and are made safe by a row lock on rotation, not by the per-app split. Retires POST /v1/auth/refresh wherever MULTI_APP_ENABLED is on — that route answers 404 there. 401 for missing/expired/replayed/wrong-chain; 403 when the grant or enablement was revoked mid-session. A COOKIE CLIENT MUST RE-STORE THE ROTATED COOKIE EVERY TIME — the server re-sets it on each rotation, and a client that falls behind the chain reads as a replay on its next renewal. BODY is strictly weaker and is a decision with a named owner: an XSS there steals a credential that outlives the tab, so it is chosen only where both alternatives are worse — a third-party cookie browsers are removing, or a full-page redirect every ten minutes. CORS: this route names the client in the PATH, so its allow-list is genuinely per-client — an origin belonging to a DIFFERENT registered client is refused exactly as an unregistered one is.

Apps the caller holds in the SESSION'S ACTIVE TENANT only — an app held in another tenant is absent, and reaching it means an explicit tenant switch first (scenario 20), which moves every open tab and is therefore a visible act rather than a side effect of picking from a list. Filtered to live product apps with an active enablement: the identity app is the shell that renders this list, and a suspended enablement would offer a door that refuses to open. Each row carries the clientId, because apps are not addressable — clients are. isCurrent is matched on the azp the gateway stamped. This list comes from the API, never from x-gateway-context, which carries only the current app as the single scalar azp.