Clarify authorization-code transport in the SSO proposal

Author: ryan-williams

specs/cross-service-sso.md

@@ -19,7 +19,7 @@ The broker keeps an HttpOnly, Secure, host-only `__Host-` cookie (`Path=/`, no `
 1. App checks local authentication. A valid explicit guest/account selection remains active; an incidental broker session must not replace it. Explicit API Bearer requests never enter browser SSO redirects. An incoming share link follows the multi-login resolution policy, not an unconditional broker escalation.
 2. With no usable local selection, the app creates a browser-bound login transaction (state, nonce and PKCE S256 verifier) and redirects to the broker's authorization endpoint. Client ID, exact registered redirect URI, requested identity scopes and an optional non-authoritative hint identify the request.
 3. Broker validates the client and redirect. If its session is valid and selection unambiguous, it issues a short-lived, one-use code bound to that client, redirect URI and PKCE challenge. Otherwise it returns a standard no-interaction error or offers an interactive sign-in/selection path. There is no arbitrary `next` URL that can receive credentials.
-4. App backend exchanges the code, validates issuer/audience/signature/nonce/expiry, then applies its **own** current email/group/resource policy and establishes a local session. Only a callback with matching state/browser transaction may select/add the account. Codes and tokens never enter localStorage, cross-service URLs, audit rows or analytics.
+4. App backend exchanges the code, validates issuer/audience/signature/nonce/expiry, then applies its **own** current email/group/resource policy and establishes a local session. Only a callback with matching state/browser transaction may select/add the account. The short-lived authorization code is delivered only to its registered callback and immediately stripped/exchanged; it must not be forwarded into unrelated URLs, localStorage, audit rows or analytics. Session, access and ID tokens never travel in those callback URLs.
 5. The app sends the visitor to the original safe local destination, stripping callback parameters. It never automatically retries an `interaction_required`/`login_required` result indefinitely. Authentication at OA is not automatic authorization for every OA service.
 
 For this backend-oriented app fleet, use authorization-code flow with PKCE and confidential client authentication where appropriate. No browser-held shared refresh credential. Token audiences and callback allowlists remain per app; a token issued for service A is not a credential for service B. The existing OIDC adapter needs a concrete interoperability/security review (discovery/provider capabilities, PKCE, error/callback handling, parameter overrides and relevant tests) before claiming broker compatibility beyond its tested configurations.