Chapter 3 · Authentication & Access· Beginner· ~13 min

Sessions, Cookies, OAuth

HTTP forgets you after every request. The whole web sits on top of a few small tricks for remembering you anyway.

You will learn

  • Why HTTP needs sessions at all
  • What a cookie is, and the flags that matter for security
  • The difference between a session cookie and a token
  • What OAuth and OpenID Connect are actually doing when you click "sign in with Google"

HTTP is stateless

Every HTTP request stands alone. The server has no memory of who you are between one click and the next. That's a fine design for serving static documents, but it makes "you're logged in" impossible without some help.

The help is a small token the server gives you after login, which your browser sends back on every subsequent request. The server looks the token up, finds your account, and treats the request as yours. That is what a session is.

Cookies, and the flags that matter

The default mechanism for that token is a cookie: a small piece of data the server asks the browser to store and re-send. Cookies are old, slightly weird, and full of feet you can shoot off. The flags that matter:

  • Secure: only send over HTTPS. Without it, a network observer can lift the cookie from any plaintext request.
  • HttpOnly: the cookie isn't accessible to JavaScript. Limits the blast radius of an XSS bug.
  • SameSite: controls whether the cookie is sent when another site initiates the request. SameSite=Lax is a sensible default; Strict for the most sensitive.
  • Domain / Path: scope the cookie to as little as possible.
  • Max-Age / Expires: shorter is better for session cookies.

Missing flags break everything else

If your session cookie isn't marked HttpOnly and Secure with a SameSite policy, a single XSS or a single insecure subdomain is enough to take over the account. The cookie flags are not optional.

Session cookies vs. tokens

Two common shapes:

  • Session cookie pointing to server state. The cookie is just an opaque ID. The server keeps the real session data (who you are, when you logged in, what scopes you have). Easy to revoke, delete it server-side.
  • Self-contained token (often a JWT). The token is the session data, signed by the server. The server doesn't need to store it; just verify the signature. Hard to revoke before the expiry, once issued, it's out there.

Neither is universally better. JWTs are convenient for stateless services; opaque session IDs are simpler to reason about and revoke. Use what fits, and understand the trade-off.

Logging in with Google: OAuth and OIDC

OAuth 2.0 is a protocol for delegated authorization: it lets a user grant one site (the "client") limited access to their account on another site (the "authorization server") without sharing their password.

OpenID Connect (OIDC) sits on top of OAuth and adds authentication: a standard way for the client to learn who the user is, in the form of an ID token.

The everyday flow:

  1. You click "Sign in with Google" on Site X.
  2. You get bounced to Google's login page (you already have a session there, so you may not even see it).
  3. Google shows you a consent screen: "Site X wants to know your email."
  4. You agree. Google sends Site X a short-lived code.
  5. Site X exchanges that code with Google's servers for an ID token and an access token.
  6. Site X creates its own session for you and you carry on.

Your password never touched Site X. Revoking access is one click in Google's account settings.

Scopes matter as much as identity

OAuth also lets you grant limited access. "Read my calendar" is a different scope than "send email as me". Always grant the smallest scope an app needs.

Take the quiz