# SameSite cookies through OAuth and federated login redirects > Trace callback method and site context before changing cookie policy so you can fix missing session or CSRF cookies without over-broadening them. Canonical URL: https://www.devobs.io/articles/samesite-cookies-oauth-redirects/ By: Maya Chen Published: 2025-08-03T16:56:15.917Z Updated: 2026-09-06T10:18:15.722Z Section: Identity Reviewed: 2026-09-06 (UTC) When an [OAuth callback](https://www.devobs.io/articles/spa-pkce-callback-hardening/) loses a session or CSRF cookie, trace the browser navigation rather than weakening every cookie. `SameSite=Lax` commonly works for a top-level GET redirect, `Strict` can withhold cookies after leaving the site, and a cross-site POST callback can require `SameSite=None; Secure`. The right setting depends on the response mode and which cookie the callback needs. ## Separate site, origin, and method Cookie scoping is determined by domain, path, security attributes, and browser same-site rules. Origin rules also consider scheme, host, and port, while “site” is a different boundary. A login journey can be cross-origin without being cross-site, or cross-site while returning to the same application origin. Record the exact URLs and methods in browser developer tools. [RFC 6265: HTTP State Management Mechanism](https://www.rfc-editor.org/rfc/rfc6265.html) defines the HTTP cookie state mechanism, including Domain, Path, Secure, and HttpOnly. Modern SameSite behavior has evolved beyond that original document, so verify target-browser behavior as part of testing rather than treating an older RFC example as a browser guarantee. Keep authentication cookies host-only when possible, use `Secure` and `HttpOnly` for session identifiers, and avoid broad domain scope. ## Follow the redirect variants With the usual authorization code flow and query response mode, the authorization server sends a top-level redirect to a callback such as `GET /callback?code=...&state=...`. Lax cookies are generally available on this top-level safe navigation, allowing the application to retrieve server-side state and correlate the response. Strict cookies may be absent because the navigation originated from another site. With `response_mode=form_post`, the [OAuth 2.0 Form Post Response Mode specification](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html) says the authorization response parameters are encoded as HTML form values and transmitted to the client with HTTP POST. A cross-site POST callback can therefore behave differently from a top-level GET redirect under browser SameSite enforcement. If the callback depends on a cookie, that specific correlation cookie may need `SameSite=None; Secure`, or the design must use a different response mode and state storage. Do not solve this by making the main application session broadly cross-site unless needed. Separate short-lived login transaction state from the long-lived session. Store opaque state server-side, bind it to the redirect destination, give it a short expiry, and consume it once. The callback can create or rotate the ordinary session after validating the authorization response. ## Keep CSRF protections intact SameSite is one layer, not a replacement for OAuth `state` or application CSRF defenses. Verify that the returned `state` exactly matches the initiating transaction record before continuing. Validate the authorization response against the initiating transaction before creating or rotating the session. For cookie-authenticated state-changing application routes, continue using an anti-CSRF strategy or strict origin checks suitable for the architecture. `SameSite=None` requires `Secure` in current mainstream browsers and intentionally permits cross-site attachment. Limit that cookie's path, purpose, lifetime, and privileges. Never put sensitive transaction data in the state parameter or a readable cookie merely to make redirects easier. ## Test a matrix, not one browser click Automate top-level GET, form POST, popup, and iframe paths if the product uses them. Test first login, returning session, expired transaction cookie, parallel tabs, back button, and browsers with third-party-cookie restrictions. Capture cookie exclusion reasons from the browser rather than inferring the cause from an application 403. Take one failing callback and write down six values: initiating site, provider site, callback URL, callback method, [cookie Domain](https://www.devobs.io/articles/cross-subdomain-session-cookie-design/)/Path, and SameSite value. Change only the transaction cookie or response mode needed for that path, then add a browser test that proves both successful correlation and rejection of a forged state. This separation also makes concurrent login tabs easier to reason about because each attempt receives its own transaction record rather than racing over one shared cookie value. ## Source references - -