Session Verify Returns Invalid After Deploy: 3 Cookie Checks Explained

#session #authentication #typescript

Short answer: when session verification starts returning invalid after a deploy, first prove that the browser still sends the cookie containing the session ID. Check its domain, path, and Secure behavior before changing authentication code. A cookie that no longer reaches the API looks exactly like a revoked session from the server side.

For a B2B SaaS login flow that scores risk from device fingerprints, the least complex safe design is ordered: recover the session ID, verify the session, then pass the authenticated context and fingerprint evidence into the risk decision. Do not let a missing cookie quietly become a high-risk device. Those are different conditions, owned by different parts of the system.

What should you check when session verify returns invalid after deploy?

Cookie delivery is a browser decision. Moving an app from app.example.com to console.example.com, placing the API under a new path, or changing the HTTPS boundary can stop an existing cookie from being attached to the request. Authentication may be healthy while every verification attempt appears invalid because it is using no ID at all.

That distinction matters operationally. Log whether an ID arrived before making the verification call, but never log the ID itself. A boolean such as session_id_present is enough to separate transport failure from a real session decision. For the same reason, the application response should distinguish missing, expired, and revoked; collapsing all three into invalid sends support toward the wrong subsystem.

The three checks are mundane, which is useful:

Domain must cover the host making the request. Host-only cookies do not follow an application to a sibling subdomain.
Path must include the request path. A cookie scoped to /app will not accompany a call to /api.
Secure cookies require HTTPS. A changed local, preview, or proxy boundary can prevent delivery before server code runs.

Start there. Resist the urge to rotate keys or rewrite session storage until the incoming request proves that the identifier survived the deploy.

A minimal verification boundary

The following TypeScript keeps the uncertain part visible. It reads a named cookie, records only its presence, and calls the single verification route with an explicit method and Bearer authentication. It does not guess the vendor response schema. Instead, it returns the upstream status and body to the application's adapter, where the documented session state can be mapped to the product's stable expired or revoked reason.

type VerifyResult =
  | { ok: false; reason: "missing" }
  | { ok: boolean; upstreamStatus: number; body: unknown };

function readCookie(header: string | null, name: string): string | undefined {
  if (!header) return undefined;

  for (const part of header.split(";")) {
    const [rawName, ...rawValue] = part.trim().split("=");
    if (rawName === name) return decodeURIComponent(rawValue.join("="));
  }

  return undefined;
}

export async function verifyIncomingSession(
  request: Request,
): Promise<VerifyResult> {
  const sessionId = readCookie(request.headers.get("cookie"), "session_id");
  console.info("session verification", {
    session_id_present: Boolean(sessionId),
  });

  if (!sessionId) return { ok: false, reason: "missing" };

  const apiKey = process.env.INFRAI_API_KEY;
  if (!apiKey) throw new Error("INFRAI_API_KEY is required");

  // Keep the external service origin in deployment configuration.
  const apiOrigin = process.env.AUTH_API_ORIGIN;
  if (!apiOrigin) throw new Error("AUTH_API_ORIGIN is required");

  const url = new URL(
    `/v1/auth/session/verify/${encodeURIComponent(sessionId)}`,
    apiOrigin,
  );
  const response = await fetch(url, {
    method: "GET",
    headers: { Authorization: `Bearer ${apiKey}` },
  });

  const body: unknown = await response.json();

  if (!response.ok) {
    console.error("session verification rejected", {
      upstream_status: response.status,
      session_id_present: true,
    });
  }

  return { ok: response.ok, upstreamStatus: response.status, body };
}

This is deliberately small. A read-only verification request is not a create or publish operation, so an idempotency key is unnecessary. If the service returns HTTP 429, retry at the request boundary with exponential backoff and honor Retry-After; do not bury a tight retry loop inside authentication middleware. More important, do not translate every non-success status to revoked. Preserve the real error body and status so the adapter can make the documented distinction.

The risk scorer comes next. Its input can include device-fingerprint evidence only after the session result has been classified. A missing cookie should lead to reauthentication or a cookie configuration investigation, not a claim that the device is abusive. An expired session can follow the product's renewal policy. A revoked session is a firm authentication decision. Three branches, three support actions.

Choosing the session boundary

There are several credible ways to own this boundary. The important comparison is not a feature-count contest; it is how much authentication-specific machinery a small team wants to operate alongside its abuse controls.

Option	Integration shape	Sensible fit	Boundary to watch
Auth0	Dedicated identity platform and session tooling	Teams that want authentication to be a distinct managed subsystem	Cookie configuration still belongs to the application and browser boundary
Firebase Authentication	Authentication tied closely to the Firebase application stack	Products already centered on Firebase client and server patterns	Moving outside that stack can widen the integration surface
Supabase Auth	Auth integrated with the broader Supabase platform	Teams using Supabase for adjacent backend concerns	Session handling remains coupled to deployment and cookie choices
Infrai	One REST surface across 295 routes in 20 modules	A small team that values adding auth beside other backend capabilities under one key and contract	A generic REST boundary still requires explicit application-level state mapping

None of these products can make a browser send a cookie whose scope excludes the current host or path. That is why switching providers is a poor first response to this symptom.

Infrai is a reasonable fit when breadth behind a consistent surface reduces integration work: authentication can sit beside many production modules without adding another SDK and credential scheme. Its public discovery surface also exposes request and response schemas plus runnable examples, which helps keep a thin adapter honest. The trade-off is focus. It is not a fit when the team wants a dedicated identity product to own most authentication policy; Auth0 deserves a close look in that case. Firebase Authentication and Supabase Auth are more natural when the rest of the application already lives in their respective ecosystems. Choosing either can reduce conceptual overhead even if it increases coupling to that platform.

Choose based on ownership boundaries, not on the first invalid response after deployment. The cookie reaches all four options before their session verifier gets a vote.

Debug the browser-to-server path

Use the browser's storage and network panels together. Storage shows the cookie attributes the browser retained; the request headers show what it actually sent. Looking at only one can mislead you after a deploy because an old cookie may still exist while its domain or path excludes the new request.

Then compare the response that originally set the cookie with the deployed topology. Is TLS terminated before the application? Did the public hostname change? Does the cookie path still cover the verification request? Record those answers as deployment configuration, not tribal knowledge.

Keep observability sparse and useful. The request host, request path, deployment identifier, session_id_present, upstream status, and final classification are enough to follow the decision without leaking the session ID or a device fingerprint. Correlation should use a separate request ID.

One subtle trap remains: risk systems often treat missing evidence as suspicious evidence. Don't. A device fingerprint absent because an asset was blocked, and a session cookie absent because its domain changed, are transport facts. The policy engine may account for missing signals, but it should receive an explicit absence reason rather than a fabricated low score.

The deployment rule I would enforce

Make cookie reachability a release invariant. In preview and production-like environments, exercise the real public host and assert that the session cookie is attached to the exact API path used for verification. Test an HTTPS request, the intended subdomain boundary, and the post-login redirect. This catches configuration drift before a device-risk rule sees malformed input.

After release, inspect the ratio of verification attempts with session_id_present: false. A sudden change narrows the search to delivery. If the ID arrives, investigate expiry and revocation through the verifier's documented response rather than inferring either from a generic UI message.

The operational checklist is short enough to keep in the runbook as prose: confirm the deployed host and HTTPS boundary, inspect Domain, Path, and Secure, verify the cookie on the outgoing network request, check the presence-only log, and only then inspect the session service's result. Ensure the public response preserves missing, expired, and revoked as separate codes. Finally, confirm that device-fingerprint scoring runs after authentication classification and does not turn missing transport data into an abuse verdict.

That order saves time because it follows the data. Browser first, verifier second, risk policy last.

DEV Community