Updated August 2026.
The question is not really about PHP. It is about the web, and the answer is the same in any language. HTTP is a stateless protocol: every request arrives with no memory of the ones before it. The server has no built-in way to know that the request asking to delete an account is the same person who logged in a moment ago. A token is how we carry that knowledge from one request to the next. It is a small piece of data the client presents to prove something the protocol itself has forgotten.
There is not one kind of token. There are three, and they prove different things. Confusing them is where a lot of security bugs begin.
Session tokens: proving identity
When you log in, the server creates a session and hands your browser a session token, usually the session ID. On every later request the browser presents that token, and the server looks up who you are. This is what keeps you logged in.
Because a session token is your identity for the life of the session, where it lives matters enormously. The right home is a cookie marked HttpOnly (so JavaScript, and therefore an XSS payload, cannot read it), Secure (so it never travels over plain HTTP) and SameSite (so other sites cannot trigger authenticated requests with it).
A word of correction to a common piece of old advice: do not put session IDs in URLs. A token in a URL leaks in ways a cookie does not. It is written to server access logs, sent to other sites in the Referer header, saved in browser history, and copied verbatim when someone shares the link. PHP could once be configured to add the session ID to URLs automatically; that behaviour is a liability, not a convenience. Keep the token in a properly flagged cookie.
CSRF tokens: proving intent
A session token proves who you are, but not that you meant to make this particular request. That gap is what cross-site request forgery abuses: another site quietly causes your browser to send an authenticated request, and the cookie rides along automatically. A CSRF token closes the gap. The server plants a secret, unpredictable value in your form or page, and requires it back on any state-changing request. A forging site cannot read that value, so it cannot forge the request. This is a different token from the session token, doing a different job: intent, not identity.
API tokens: proving authorisation without a session
For APIs, mobile clients and server-to-server calls, there is often no browser and no session at all. Here the client sends a bearer token, an API key or an OAuth access token on each request, typically in an Authorization header. The value proves the caller is authorised to act. A good pattern is short-lived tokens that are refreshed deliberately by your own code, so a leaked token expires quickly rather than lasting forever. OAuth formalises this dance of issuing, presenting and refreshing tokens.
How Laravel implements all three
Modern frameworks give you each of these out of the box, which is exactly why understanding the distinction pays off:
- Session tokens: Laravel manages the session cookie for you, with the secure flags configurable in
config/session.phpand.env. - CSRF tokens: the
webmiddleware verifies a token on every state-changing request, and Blade’s@csrfdirective drops the hidden field into your forms. - API tokens: Laravel Sanctum issues and checks bearer tokens for SPAs and mobile clients, and Passport provides full OAuth2 when you need it.
In one line, the reason we use tokens: HTTP forgets everything between requests, so a token is how the client reminds the server of what it is allowed to do, and choosing the right kind of token for the job is half of getting web authentication right.
Related
- Laravel Security Review: a practical walk through reviewing and hardening a Laravel application, area by area, with every guide in this cluster in one place.
- Securing Authentication and Authorization in Laravel: sessions, Sanctum, and closing access-control gaps.
- Preventing the OWASP Top 10 in Laravel: where CSRF and broken authentication sit in the risk list.
