The direct answer

Associate an OAuth authorization response with one server-owned pending initiation bound to the initiating user agent, session, workspace and configured issuer. Use that record for client, redirect and PKCE verifier selection, then separately validate the exchange and current authority before attaching a grant.

Start with the workspace that requested the connection

A fictional assistant console starts connecting an external notes account for workspace W-A. Before the authorization response returns, the user opens W-B in another tab. The connection must not silently follow the currently selected workspace. This is an enrollment boundary, earlier than checking a downstream token's audience or authorizing a note.

This guide proposes one server-side confidential authorization-code client with PKCE S256, HTTPS endpoints and a preconfigured issuer I-A. Its deployment must establish actual support for PKCE and RFC 9207 issuer responses before enabling this profile. No provider compatibility is assumed. All labels below are inert references, not usable codes, state values, verifiers, tokens or endpoint addresses.

Declare the protocol and the stricter application policy

RFC 9700 sections 2.1–2.1.1 require client CSRF protection, recommend PKCE for confidential clients, and require transaction-specific challenge binding to the client and initiating user agent. Our profile additionally uses one-time, unpredictable, session-bound state to locate a stored initiation. It never encodes a callback-selected workspace as trusted authority. These combined controls are not interchangeable.

RFC 7636 sections 4.1–4.6 associate each request's verifier-derived challenge and method with its code; the token endpoint checks the later verifier. Explicitly select S256. An implementation must meet the specification's verifier generation and encoding rules; V-A here is only a reference label. PKCE does not decide which application workspace receives a connector.

Write one pending record per initiation

After authenticating the user and authorizing connection setup for W-A, propose a server-owned record T-A. Bind its immutable fields to the browser/session context; do not replace a single session-wide “latest connection” record when a second tab starts T-B.

PROPOSED_UNRUN — symbolic worksheet only
T-A: user U-A; session S-A; workspace W-A
     issuer I-A; configuration revision CFG-4
     client CL-A; redirect R-A; verifier reference V-A
     purpose notes.read; expiry E-A; status pending
T-B: user U-A; session S-A; workspace W-B
     issuer I-A; configuration revision CFG-4
     client CL-A; redirect R-A; verifier reference V-B
     purpose notes.read; expiry E-B; status pending

The real state proof would locate and authenticate association with exactly one record, with tampering and swapping prevented. T-A is not itself that secret proof. Expiry E-A is a proposed local deadline, separate from the authorization server's code lifetime. Keep real credentials outside prompts and ordinary logs.

Check association before selecting an exchange destination

Require the expected single state association, current bound user/session, unused and unexpired initiation, expected response shape, and unchanged configuration identity. Reject ambiguous duplicate security parameters or a mixture of success and error. Callback fields cannot enroll an issuer, select an endpoint, substitute a verifier or retarget W-A.

RFC 9207 sections 2–4 specify issuer indication in success and error responses for supporting servers. Decode the response's iss parameter using the specified form encoding, then compare it with the stored expected issuer by simple string comparison. Our configured-support profile rejects missing or mismatching iss before exchange. This parameter is not cryptographically protected and does not alone authenticate the response. A single-issuer client is not subject to the multi-server mix-up threat; requiring this extension here is a deliberate compatibility restriction. Adding issuers requires a fresh configuration review.

This redirect is expected to arrive through an authorization flow. Do not transplant the separate same-origin approval POST's Origin or Fetch Metadata allowlist onto it.

Review eight proposed response cards

Each row is independent and PROPOSED_UNRUN. “Validated grant” is a future prerequisite, never a result observed here.

Original initiation-to-attachment worksheet
CaseAssociation and current conditionRequired disposition
Positive T-AMatching session, issuer and configuration; current W-A authorityClaim T-A; exchange with its bindings; attach only validated grant to W-A
No matching initiationMissing, foreign or ambiguous state associationReject; do not create a record from response fields
Another tab shows W-BT-A still binds W-ARetain W-A; show that target explicitly before completing attachment
Parallel records crossedT-B response proposed with V-AReject inconsistent association; never try every stored verifier
Issuer differs or is missingI-B or no iss under configured supportReject before selecting the trusted token endpoint
Registration changedClient, redirect or CFG-4 no longer approvedHold; start a newly authorized initiation rather than repair T-A
Duplicate or uncertain completionT-A claimed, completed or exchange outcome unknownConsult durable disposition; no second exchange or reassignment to T-B
Local authority changedSession replaced, T-A expired, or W-A connection right revokedReject or hold; matching state does not restore authority

Separate exchange, grant evidence and attachment

Coordinate a pending-to-claimed transition with the admission checks using supported durable state; a separate read then claim can race. RFC 6749 sections 3.2.1 and 4.1 require confidential-client authentication and bind a code to its client and redirect. Because this profile supplies redirect_uri initially, the exchange must supply the identical value. Use T-A's trusted token endpoint, registered client authentication, redirect and verifier association. The server's actual code and PKCE checks remain necessary; local metadata cannot establish them.

Record an uncertain exchange as unknown, not unused. RFC 6749 prohibits code reuse; a timeout is not permission for automatic redemption retries. Reconcile through the actual integration's documented behavior without silently attaching an unconfirmed grant.

Before attachment, require validated exchange evidence, the actual granted scope, and integration-specific evidence of the external account being connected. RFC 6749 section 3.3 distinguishes requested from granted scope; a code alone proves neither the intended account nor local workspace permission. This worksheet implements no account-identification protocol. Keep the grant unusable until those gates and current W-A authority pass, coordinating the final local authorization check and attachment. Show the confirmed workspace and supported account identity explicitly.

Keep evidence and product scope honest

A future review should trace one initiation through association, claimed exchange, validated grant and authorized attachment, including concurrent responses and a lost exchange response. All eight cases remain unrun: no OAuth client, flow, credentials, browser session, account, discovery, exchange or model experiment occurred.

Boundary is a prelaunch model request router; its planned checks do not provide this connector enrollment service. The available synthetic action exercise and eight mock evaluator tests establish different, limited evidence.

Primary sources

Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.

  1. RFC 9700 — OAuth 2.0 Security Best Current Practice
  2. RFC 7636 — Proof Key for Code Exchange
  3. RFC 9207 — Authorization Server Issuer Identification
  4. RFC 6749 — OAuth 2.0 Authorization Framework