Token Implementation In PHP

The earlier lessons in this track designed authentication flows; this one covers the two concrete mechanisms PHP uses to carry a proven identity across requests — sessions and JWTs — and how to implement each safely. The choice between them is one of the most consequential and most misunderstood decisions in web auth, so start there.

Sessions Versus JWTs

A session stores the state on the server and hands the browser only an opaque session ID in a cookie. Each request, the server looks up the ID to find who the user is. A JWT puts the identity in the token itself — a signed, self-contained claim the server validates without a lookup.

The trade is the mirror image of each other:

• Sessions are revocable instantly (delete the server record) but require server-side storage that every request consults — trivial on one server, needing shared storage (Redis, database) across a fleet.
• JWTs are stateless and scale effortlessly (no lookup) but are not revocable before expiry, because nothing is checked against a server record.

The practical guidance is unfashionable but correct: for a server-rendered web application, sessions are usually the better default. They are simpler, revocable, and PHP has them built in. JWTs earn their place for stateless APIs, cross-service auth, and mobile clients — and even then, the access/refresh split pairs a stateless access JWT with a revocable server-side refresh token precisely to buy back the revocability JWTs lack. Reaching for JWTs to log into a monolith is a common cargo-cult mistake.

Sessions Done Right In PHP

PHP's session handling is solid; the security is in the cookie flags and a couple of disciplines:

<?php

declare(strict_types=1);

// Set before session_start(), typically in php.ini or via session_set_cookie_params.
$cookieParams = [
    'httponly' => true,   // JavaScript cannot read the cookie (blunts XSS theft)
    'secure'   => true,   // sent only over HTTPS
    'samesite' => 'Lax',  // not sent on cross-site requests (blunts CSRF)
    'path'     => '/',
];

echo 'httponly=' . ($cookieParams['httponly'] ? 'yes' : 'no') . PHP_EOL;
echo 'secure=' . ($cookieParams['secure'] ? 'yes' : 'no') . PHP_EOL;

// Prints:
// httponly=yes
// secure=yes

Three flags carry most of the security: HttpOnly keeps the session ID out of JavaScript's reach so an XSS bug cannot exfiltrate it; Secure keeps it off plaintext HTTP; SameSite stops the browser from attaching it to cross-site requests, which is a strong CSRF defense. Two disciplines complete it: regenerate the session ID on privilege change (session_regenerate_id(true) at login) to defeat session fixation, where an attacker plants a known ID before login and inherits the authenticated session; and set an idle timeout and absolute lifetime so abandoned sessions die. Store sessions in Redis or the database once you run more than one server, or users bounce between servers that do not share session state.

JWTs Done Right In PHP

A JWT has three parts — header, payload, signature — base64url-encoded and dot-joined. The signature is the entire security: it proves the token was minted by you and not altered. Use a maintained library (firebase/php-jwt or lcobucci/jwt), never hand-roll parsing, and observe the non-negotiables:

• Verify the signature on every request, and pin the algorithm. The infamous JWT vulnerability is the alg: none / algorithm-confusion attack, where an attacker changes the header to claim no signature (or tricks an RS256 verifier into accepting an HS256 token signed with the public key). Always specify the expected algorithm to the verifier rather than trusting the token's own header.
• Validate the standard claims: exp (expiry — reject expired), iss (issuer), aud (audience — the token was minted for you), and nbf/iat as appropriate.
• Keep the payload non-secret. A JWT is signed, not encrypted — anyone can base64-decode and read it. Never put passwords, secrets, or sensitive personal data in the claims.
• Protect the signing key like any other secret, and keep access-token lifetimes short because, as established, you cannot revoke a JWT before it expires.

Where Tokens Live In The Browser

For browser clients, prefer an HttpOnly cookie over localStorage for anything long-lived. localStorage is readable by any script, so an XSS flaw becomes token theft; an HttpOnly cookie is not script-readable. If you must hold an access token in the page (common for SPAs calling APIs), keep it in memory only and rely on a refresh flow, so there is no persistent store for an attacker to loot. Cookies bring CSRF into scope, which SameSite plus CSRF tokens handle — the trade is deliberate, not accidental.

What To Check

Before moving on, make sure you can:

• state the session/JWT trade-off and default to sessions for server-rendered apps
• set HttpOnly, Secure, and SameSite and say what each defends
• regenerate session IDs on login and explain session fixation
• verify JWT signatures with a pinned algorithm and validate exp/iss/aud
• explain why a JWT payload is readable and must hold no secrets
• choose browser storage (HttpOnly cookie or memory) over localStorage

What You Should Be Able To Do

After this lesson, you should be able to implement secure PHP sessions with correct cookie flags and fixation defense, implement JWT validation that resists the algorithm-confusion attacks, choose between sessions and tokens on the merits rather than fashion, and store tokens in the browser without creating an XSS theft primitive.