Glossary — browser, cookies & storage (sign-in)
How browsers handle cookies and storage directly affects redirects, popups, and sessions. This is help text, not security audit guidance.
First-party vs third-party context
Meaning: First-party — the cookie or storage is tied to the site the user sees (your registrable domain). Third-party — tied to another site’s domain (e.g. an iframe or cross-site request).
In practice: Sign-in flows that cross domains (your site ↔ IdP) are sensitive to third-party cookie restrictions; prefer first-party redirects and patterns described in Sessions, cookies, and tokens.
SameSite (cookie attribute)
Meaning: Tells the browser when to send a cookie on cross-site requests — values like Strict, Lax, None (often with Secure).
In practice: Wrong SameSite settings cause silent failures after login or on callbacks; compare working vs broken environments in Application → Cookies.
HttpOnly
Meaning: Cookie not readable from JavaScript in the browser — reduces XSS theft of session cookies when used for session IDs.
In practice: If your app stores tokens in memory or non-HttpOnly storage, threat models differ; follow your security team’s standards.
Secure flag
Meaning: Cookie is only sent over HTTPS.
In practice: Required for production sign-in; mixed http/https callbacks break OAuth-style flows.
Local storage / session storage
Meaning: Origin-scoped key/value storage in the browser — survives reloads (local) or tab session (session).
In practice: Do not store refresh tokens or long-lived secrets here unless your threat model explicitly allows it; many teams prefer HttpOnly cookies or server-side sessions for high-risk tokens.
Storage partitioning
Meaning: Browsers increasingly isolate storage per top-level site or frame so third parties cannot easily share identifiers cross-site.
In practice: Explains why iframes and embedded login are harder than top-level redirects; test Safari and Chrome with real domains.
Third-party cookie “phase-out”
Meaning: Browsers are restricting third-party cookies by default; some vendors use CHIPS, related website sets, or other mechanisms.
In practice: Rely on documented Intastellar patterns and first-party redirects rather than assumptions from older OAuth tutorials.
Last updated