MFA session should be resumable without a cookie (backend SDKs) #784

Activity

1. lakhansamani commented on Aug 17, 2026

   

   lakhansamani

   on Aug 17, 2026

   ContributorAuthor

   More actions

   Closing against the finding rather than implementing it: the mechanism already exists.

   What I verified

   The handle is already on the wire, and the server already accepts it from a plain header. End to end against a default-config server:

   # 1. signup withholds the token AND publishes the handle
   {"data":{"signup":{"access_token":null,"message":"Proceed to mfa setup"}}}
   Set-Cookie: mfa_session=e415fa93-f51e-4ee1-8568-bd7cf2e0fa67
   
   # 2. complete it with a MANUAL Cookie header — no jar, no policy, no new field
   access_token issued: True
   message           : MFA setup skipped
   

   gRPC is the same: cookiesFromMetadata (grpc_metadata.go:158) reads a cookie metadata key, and outbound cookies are serialised to set-cookie metadata.

   Why this is better than the body field I proposed

   I planned return_mfa_session plus mfa_session across eleven inputs and a response type. That would have been strictly worse:

   	Server change	New API	Browser exposure	SDK complexity
   Header echo (exists today)	none	none	unchanged	low
   Body field + opt-in flag	yes	2 fields × 11 inputs	new, needs managing	low

   A body field puts the handle somewhere it has never been, then needs a forgeable opt-in flag to keep it off the browser path. The header echo puts it nowhere new — Set-Cookie is already sent to every client on these calls. No new exposure means no flag to get wrong, and the server-side threat model is literally unchanged.

   To be explicit, since it can look like one: this is not an HttpOnly bypass. HttpOnly constrains browser script, not HTTP clients. Page script still cannot read the cookie.

   The actual bug

   Nobody documented that the handle was readable. The docs said "the frontend authenticates the follow-up call…", so two SDKs independently built user-agent emulation for a two-line problem — and the Python one took two attempts and produced a cookie-injection hole along the way.

   Fixed:

   • docs(mfa): the MFA session is not browser-only docs#93 — states the handle is not browser-only, gives the two-command recipe and the gRPC equivalent, and writes down the one invariant a jar gave for free: attach it only to your configured base URL, never across a redirect.
   • refactor(cookies): replace the cookie jar with the store gRPC already uses authorizer-py#15 — replaces the jar with the plain store the gRPC transport already used. Secure and Max-Age=0 still honoured; origin scoping is now structural. Verified on 3.9–3.13 plus a live MFA flow and the 56-test integration suite.
   • Go's stdlib jar is already correct (it implements the Secure Contexts loopback exception), so it needs no change.

   What would justify reopening

   If the handle ever needs to go somewhere a header cannot — a redirect-based flow carrying it in a query parameter, or a non-HTTP transport. Neither exists today. Vendor parity alone (Cognito's Session, Auth0's mfa_token, Okta's stateToken) is not sufficient reason for new API surface when the existing transport already works for every client.
2. lakhansamani

   closed this as completedon Aug 17, 2026