Series: Web Authentication Demystified — From Concepts to Real-World
ARC 2 — APPLYING THE THEORY: MY REAL IMPLEMENTATION
Previous: Deep Dive: The User Authentication Flow in my implemented Web App
Next: Lessons Learned & Practical Advice for Developers from my implemented Web App

A secure authentication system is built on more than just correct protocol usage—it’s the result of dozens of defensive decisions layered together. In the CSL platform I implemented, every redirect, cookie flag, validation step, and session write serves a specific purpose in protecting government-issued identities and safeguarding teacher data.

This article examines the security posture of the CSL authentication system: the threats it mitigates, the best practices applied, and where the architecture could evolve further. Think of this as the “why” behind the behavior described in the previous articles.

Disclaimer

The articles in this current arc are based on a real authentication system I integrated and implemented for a government education department. Due to the Non-Disclosure Agreement (NDA) between myself and the client, certain internal details, configurations, and architectural specifics have been intentionally generalized or omitted. All explanations focus on the conceptual and technical patterns rather than sensitive operational information. I’ve made every effort to describe the system as accurately as possible while fully respecting confidentiality and security requirements.

1. CSRF Protection: The state Parameter

Cross-Site Request Forgery (CSRF) is a classic attack where a malicious site tricks a user’s browser into making unintended requests.

OAuth2 defends against this using the state parameter—a random, unguessable value my application generates before redirecting the user to the IdP.

How CSL uses state

• A secure random value is generated

• Stored server-side (in session context)

• Added to the /authorize request

• Verified when the IdP redirects back

If the state value doesn’t match, the login flow is immediately rejected.

Effect

This prevents attackers from injecting fraudulent authorization responses or hijacking a login session.

2. Replay Protection: The nonce Parameter

OIDC adds a nonce field to defend against replay attacks—where an attacker tries to reuse a valid login response.

How CSL uses nonce

Even when the IdP does not issue an ID token, the client library enforces a replay check:

• The nonce is included in the request

• Confirmed on return from the IdP (if ID token present)

This small addition eliminates a category of token replay vulnerabilities.

3. Token Validation & Signature Checks

Once the CSL backend exchanges the authorization code for tokens, it performs several critical validation steps:

✔ Verify the token signature

Using the IdP’s JWKS endpoint, CSL verifies that the access token:

• was signed by the authorized public key

• matches the expected algorithm

✔ Validate claims

Even without relying on ID tokens, the access token must pass:

• iss check (correct issuer)

• aud check (this client ID)

• exp check (not expired)

✔ Ensure the user identity (sub) is present

sub acts as the canonical, stable government identity for mapping the user.

Effect

This protects against token forgery, tampering, expired tokens, and tokens issued to other clients.

4. Session Fixation Prevention

Session fixation attacks occur when an attacker forces a victim to use a known session ID.
My system avoids this by always generating a fresh PHP session when a user authenticates successfully.

Process:

• Existing session (if any) is discarded

• A new session ID is created

• Redis stores the new user context

• PHPSESSID is regenerated and delivered securely

Effect

Attackers cannot reuse or hijack a pre-established session.

5. Secure Cookies: HttpOnly, Secure, SameSite

Browser cookies are a high-value target, and my system hardens them using all recommended flags:

HttpOnly

Prevents JavaScript from reading the session cookie.
Mitigates token/session theft in XSS scenarios.

Secure

Cookie is transmitted only over HTTPS.
Protects against network sniffing and MITM attacks.

SameSite=Lax/Strict

Restricts cookie sending during cross-site requests.
Reduces CSRF risk for session-bearing requests.

Effect

Together, these flags close off several major browser-based attack paths.

6. Short-Lived CloudFront Signed Policies

The system also secures access to protected static resources (documents, files, videos) using CloudFront signed cookies.

These cookies:

• use short-lived policies

• expire quickly (limit window of misuse)

• contain cryptographically signed statements controlling access

Effect

Even if the CloudFront cookie leaks, its utility is extremely limited due to short expiration and path-restricted policies.

7. Why the Hybrid Approach Is Secure for PHP Systems

My authentication system intentionally avoids putting access tokens or ID tokens into the browser. This design has clear security benefits:

✔ Tokens never touch the frontend

No access token in localStorage, sessionStorage, JavaScript memory, or cookies.
Dramatically reduces:

• XSS token theft

• token replay

• session impersonation

✔ Server session is authoritative

Revocation is instant—delete the session from Redis and the user is logged out everywhere.

✔ The IdP remains the source of truth for identity

This avoids password handling, MFA storage, or identity management complexity within CSL.

✔ Fits PHP’s built-in strengths

PHP applications were designed around server-side sessions; this model enhances that maturity rather than fighting against it.

8. Potential Improvements

While the system is already secure and appropriate for its environment, several modern enhancements could be considered if requirements evolve.

PKCE

Not required for confidential server-side apps, but many IdPs now mandate it for best practice.

ID Tokens

While access tokens are validated, ID tokens could offer:

• standardized identity claims

• nonce verification

• clearer user identity structure

Refresh Token Rotation

Could improve long-lived session security for APIs interacting with the IdP.

MTLS (Mutual TLS)

Provides extremely strong service-to-service authentication, especially between CSL and internal APIs.

Session Invalidation Hooks

Automatic invalidation when user status changes in external systems.

More granular audit trails

Tracking:

• authentication attempts

• token exchanges

• session creations

• CloudFront policy issuance

9. Logging, Monitoring & Audit Trails

A secure authentication flow relies not just on prevention but also on detection.

Current security posture includes:

• Logging all token exchanges

• Recording user_auth provisioning

• Tracking failed logins

• Monitoring session creation & destruction

Enhancements could include:

• Audit dashboards

• Alerts for suspicious patterns (e.g., repeated auth failures)

• Correlation IDs across redirects

• Token validation telemetry

Monitoring ensures that unusual behavior doesn’t go unnoticed.

Final Thoughts

This authentication system layers multiple defenses—from state verification to secure cookies to strict token validation—to ensure that government-issued identities and teacher data are protected at every step. The hybrid approach blends OIDC identity assurance with the safety and controllability of server-side PHP sessions, creating a model that is both secure and well-suited to my application architecture.

With the security foundations now fully examined, we can step back and reflect on what this entire journey reveals about real-world authentication systems. The next article in the series will look at the lessons learned—what worked well, what proved trickier than expected, and why real systems rarely resemble the neat textbook diagrams. We’ll also explore practical advice for teams integrating external IdPs into legacy or session-based environments, and consider what the architecture might look like if it were redesigned today.