Direct Sign-In lifecycle

The complete flow resumes after the user authorizes on the company's page. The host consumes the pending state exactly once, verifies the callback, exchanges the code with PKCE and proof-of-possession, and requires the response to upgrade the same Session. Partial consent is an ordinary result, not an excuse to silently widen access.

What the example proves

• Callback state is consumed before exchange, so denial, failure, and success cannot leave replayable state behind.
• Redirect location, issuer, state, expiry, content type, response size, token type, sign-in status, Session ID, and scopes are all validated.
• A nonce retry reuses the one authorization code and PKCE verifier but creates a fresh client assertion and fresh DPoP proof.
• The company cannot return scopes the user did not request. Missing scopes are reported so the application can degrade safely or explain the limitation.
• The Account Token moves into the host's pap.tokenStore before complete() returns: the result carries only account_token_reference, and its token has no refresh_token. Session and Account Tokens do not enter URLs, logs, analytics, React state, or model transcripts.

The example intentionally grants only orders:read from a request for both read and return access. It also submits the callback twice and reports that the second attempt was rejected.

Run the Pydantic AI example or the Agent Runtimes example. See the detailed Direct Sign-In guide.