Signing in through an app's authorization request (OAuth 2.1)

NOT callable with fetch: it answers 302 and carries NO CORS headers under any circumstances (per OAuth 2.1), because it is reached by navigation. Use ⟳ Generate then “Open in a new tab”, and paste the ?code= you land on back into the box — it is handed to the token card below together with the matching verifier. THREE outcomes, all redirects: live session + app granted and enabled → ?code=; live session WITHOUT the grant → ?error=access_denied back to the APP (bouncing a signed-in-but-unentitled user to login would create a loop in which signing in successfully cannot fix the reason for the bounce); no live session → IAM_LOGIN_URL?return=…. The one non-redirect answer is 422, identical for an unknown client_id and an unregistered redirect_uri, with no echo of the submitted URI — there is nowhere safe to redirect an error to, and bouncing to an attacker-supplied URI to report it would be the open redirect this endpoint exists to prevent. Authenticated by the iam_sso cookie alone (HttpOnly; Secure; SameSite=Lax; Path=/v1/oauth/authorize) — Lax is required rather than chosen, because the cookie must ride a cross-site top-level GET, and the exact Path is what pays for it. 404 when MULTI_APP_ENABLED is off.

identifier is an email OR an E.164 phone — the shape decides the lookup ({ email } is still accepted as a deprecated alias) — and it is OPTIONAL on a recognised device, where the device_token cookie names the account and the body needs only { password }. Three possible answers: { accessToken, … } (nothing left to prove — auto-captured as the active bearer), { challengeToken, challenge, remaining } (a device and/or MFA hop is pending — continue at scenario 11/12/13), or the legacy { mfaRequired, method, mfaToken } shape when DEVICE_TRUST_ENABLED is off (scenario 12). Gated by the LOGIN policy before the credential is even checked → 403 login_method_disabled (scenario 7).

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.

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.