[jalexw]

Problem

Logging in to a third-party client app failed on every iPhone with Did not receive user data from auth server after login, for example lorahworld.jalexw.ca against auth.schemavaults.com. Desktop Chrome worked.

Outside development and test, the browser SDK asked the token endpoint for refresh_token_delivery=http_only_cookie. The refresh token was then set as an HTTP-only cookie on the auth server's host, in answer to a credentialed fetch from the client's page. When the page is on another site, that is a third-party cookie. WebKit blocks third-party cookies outright, and every iOS browser is WebKit, so the cookie was dropped. The code exchange succeeded, the follow-up whoami got a 401, and handleSuccessfulAuthentication threw. Desktop Chrome still accepts third-party cookies, which is why only phones failed.

I reproduced this end to end:

• the real auth server and the example resource server, on two HTTPS sites;
• Chromium with third-party cookies blocked: Set-Cookie BLOCKED [ThirdPartyPhaseout] on POST /api/oidc/token, then GET /api/auth/whoami/<app> returned 401, then the same error.

What changes

Where a client app's refresh token lives (auth-react-provider): doesSupportHttpOnlyRefreshToken() is deterministic.

App	Refresh token storage
The auth server's own app	The auth server's HTTP-only cookie (unchanged)
Client app with session routes (the default for codegen'd apps)	HTTP-only cookie on the app's own host (see below)
Any other client app	Rotating refresh token in localStorage, presented as Authorization: Bearer

The auth server's own cookie is never used for a client app any more. An earlier commit on this branch guessed same-site-ness by probing which host suffixes accept cookies; commit a025d4a removed it.

Same-origin session routes (@schemavaults/auth-server-sdk/auth-session-route, written by codegen):

• one route file each:

  Codegen route file	Factory	Exports
  auth/session/token/route.ts	createAuthSessionTokenRoute()	{ POST }
  auth/session/whoami/route.ts	createAuthSessionWhoamiRoute()	{ GET }
  auth/session/logout/route.ts	createAuthSessionLogoutRoute()	{ POST }

• each forwards its request to the auth server server-to-server;

• the refresh token lives in a host-only HttpOnly; SameSite=Strict; Path=/ cookie on the app's own host, named __Host-schemavaults_refresh_token_<app> with Secure outside development and test:

  • browsers refuse a __Host- cookie that has a Domain or a narrower Path, so a sibling subdomain can't plant one. Under __Secure-, evil.example.com could set Domain=example.com; Path=/auth/session/token, and the browser would send that cookie first, so the route would present the attacker's refresh token (session fixation);
  • a request that carries the cookie name twice is treated as having no session;
  • since the prefix requires Path=/, the cookie is no longer scoped to /auth/session, and the cookie_path option is gone;

• the refresh token is stripped from every response body;

• cross-origin requests are refused, and the token route refuses other apps' clients and other grant types.

Client SDK configuration:

• auth-client-sdk: the adapter's getSessionRouteUrls() returns each route's own URL (AuthSessionRoutes: { token, whoami, logout }), and AUTH_SESSION_ROUTE_PATHS names codegen's paths.
• auth-react-provider: <AuthProvider session_routes> takes one path or URL per route. The generated auth-provider.tsx passes AUTH_SESSION_ROUTE_PATHS; null opts out.

Auth server:

• Token endpoint fix: a refresh grant that presented its refresh token as the app's HTTP-only cookie used to get the rotated token back in the JSON body unless it asked for cookie delivery, so a script on the client's page could make the browser send the cookie and read a fresh refresh token. Such grants now always rotate the token back into the cookie. Covered by a unit test and an E2E spec.
• Logout: POST /api/auth/logout/{client_app_id} also revokes a refresh token presented as Authorization: Bearer, but only one issued to that app. The SDK's logout uses it for localStorage tokens, and the session routes use it too.

Other SDK changes:

• Bearer-authenticated whoami calls send no cookies, so a stale cookie can't take the Bearer token's place.
• In session-route mode, logout also revokes any session an older SDK left in the auth server's cookie.

Build: auth-server-sdk's turbo build inputs now include the codegen templates' src/** (via $TURBO_ROOT$) and its build scripts. A template-only edit used to be a cache hit that kept the old templates in dist.

E2E: the example resource server uses the session routes. ExampleResourceServer.cy.ts now checks for the routes' HTTP-only cookie (with or without the __Host- prefix), where it used to look for a refresh token in localStorage. New specs cover cookie-presented refresh rotation and Bearer logout.

Verification

• Browser drive with session routes. Real auth server and example app on two HTTPS sites, Chromium with third-party cookies blocked (iOS-like) and allowed (desktop-like). In both modes:
  • login, a refresh grant, the protected API call and logout all go through the three routes;
  • the session cookie is __Host-, host-only, with Path=/;
  • after logout, the auth server rejects the old refresh token;
  • a page script never obtains the refresh token: document.cookie, the token route and the auth server directly all came back without it.
• Browser drive with a sibling subdomain. A page on evil.<parent> tried to plant both the __Host- and the __Secure- session cookie with Domain=<parent>; Path=/auth/session/token:
  • Chromium refused the __Host- one (InvalidPrefix);
  • it kept the __Secure- one and sent it first to the token route, but the route ignores that name;
  • the victim's login, refresh (POST /auth/session/token 200) and API call still worked.
• Browser drive without session routes. Routes switched off in the example app, same two modes: login succeeds, with the refresh token in localStorage.
• Fast checks. Typecheck passes for every package, lint for every changed package, and all unit-test tasks pass (bun run test; 106 in auth-server-sdk, including the host-only cookie and planted-duplicate cases). The example app's typecheck (after next typegen) and route-catalogue test pass with the generated routes.
• Turbo inputs. In dry runs, editing a template changes the auth-server-sdk#build hash, and reverting the edit restores it.
• Not run here: the Cypress E2E suite, because the Cypress binary download is blocked in the sandbox. CI will run it, including the new and updated specs.

Notes

• Re-login after upgrading. Client apps sign in once more; old auth-server-cookie sessions are revoked the first time users are signed out.
• Same-site apps without session routes. They move from the auth server's cookie to localStorage; adding session routes gives them an HTTP-only refresh token again.
• Cookie sent app-wide. With Path=/, the browser sends the HTTP-only refresh cookie with every request to the app's host, not only the session routes. Page scripts still can't read it, and other sites can't trigger it (SameSite=Strict), but the app's own server code and request logs can see it.
• Rate limit. Refresh grants proxied through the token route count against the app server's IP in the auth server's per-IP refresh limit (30 per minute).
• Remaining exposure. A malicious script running while the page is open can still use the session, for example to get short-lived access tokens or start a new authorization flow. This is inherent to browser-based public clients; it can no longer take the refresh token away.
• Downstream. After publishing, lorahworld needs @schemavaults/auth-react-provider@0.18.2 and @schemavaults/auth-server-sdk@0.33.4.

🤖 Generated with Claude Code

https://claude.ai/code/session_01M5jiRPDFNryfTq79Wyp5nT