DEV Community: Suresh Ramakrishnan

Secure Your Frontend Application (SPA) Login with OAuth 2.1 PKCE

Suresh Ramakrishnan — Sun, 29 Mar 2026 02:48:09 +0000

If your frontend application (SPA) is using auth0, okta, Keycloak, Laravel Passport, or any OAuth-based solution—and you have not yet implemented the PKCE flow for login—you should do it as soon as possible. This is essential to make your application more secure against attackers.

If not, it is like making the key to your secure building publicly accessible, allowing anyone to walk in without restriction.

The Authorization Code Flow with PKCE was introduced in OAuth 2.0 and is now a core requirement in OAuth 2.1 to improve the security of frontend applications. Today, it is considered mandatory to follow this standard.

🔐 Why PKCE is Needed

What is PKCE?

PKCE (Proof Key for Code Exchange) is a security extension to OAuth 2.0 designed to protect the authorization code flow, especially for public clients like Single Page Applications (SPAs). It is now mandatory in OAuth 2.1.

Before diving into PKCE, let’s first understand the security risks in the older approach.

In traditional OAuth implementations, confidential clients used a client_secret to exchange the authorization code for tokens.

However, in SPAs (public clients), storing a client_secret is not secure or recommended, as it can be easily exposed.

👉 Important: SPAs should never store a client_secrt

🚨 Security Risk:

If a client_secret is used in a SPA, it can be easily extracted by an attacker. Combined with an intercepted authorization code, this could allow the attacker to obtain access tokens—leading to serious security issue

How PKCE Solves This Problem

Before getting into the technical flow of PKCE, let’s understand it using a simple analogy.

🎬 Smuggler Analogy (PKCE Simplified with Flow)

Imagine a secure deal where a Smuggler (SPA / Frontend Application) wants to collect cash from a Boss (Authorization Server). To prevent fraud, the Boss uses a clever verification method involving a split note and a serial number.

🔗 Concept Mapping (Analogy → Real Terms)

Smuggler (SPA) → Frontend Application
Boss (Authorization Server) → Auth Server
Split Note → code_challenge
Other Half of Split Note → code_verifier
Serial Number → SHA-256 (used to derive challenge)
Courier → HTTP Requests
Cartel → User Database
Pickup Code → authorization_code
Cash → access_token

Smuggler Analogy Flow Diagram

Step-by-Step Flow Explanation (Analogy)

1. Smuggler prepares the deal (Login Request Initiation)

The Smuggler (SPA) creates:

A split note (code_challenge derived from code_verifier)
A *serial number (SHA-256 logic used to generate it)

He sends:

One half of the split note (code_challenge)
Along with the request via the courier (HTTP request)

to the Boss (Authorization Server).

2. Boss stores and redirects (Authorization Request Step)

The Boss (Authorization Server):

Receives the split note (code_challenge)
Stores it temporarily along with the serial number logic (SHA-256)

He then redirects the Smuggler (SPA) to log in and verify identity.

The Cartel (User Database) validates the Smuggler’s credentials.

3. Boss issues pickup code (Authorization Code Issued)

Once the Smuggler (SPA) is successfully authenticated:

The Boss (Authorization Server):

Issues a pickup code (authorization_code)
Redirects the Smuggler to the designated place to receive the money (frontend callback URL

4. Smuggler sends proof (Token Request Step)

The Smuggler (SPA) now sends another request to the Boss with:

The pickup code (authorization_code)
The other half of the split note (code_verifier)

via the courier (HTTP request)

5. Boss verifies and releases cash (Token Exchange)

The Boss (Authorization Server) now:

Merges the two halves of the split note and verifies the serial number
Encrypts the received code_verifier using SHA-256
Generates a code_challenge from it and compares it with the previously stored code_challenge

✅ If they match, the Boss releases the cash (access_token)

🎯 Why This Flow is Secure

Even if an attacker intercepts the pickup code (authorization_code), they cannot get the cash (access_token) without the other half of the split note (code_verifier).

👉 This ensures that only the original Smuggler (SPA) who initiated the request can complete the process

🔐 OAuth 2.1 PKCE Flow (Technical Overview)

PKCE Flow Diagram

Step-by-Step Technical Flow

1. SPA generates PKCE parameters
The SPA (Frontend Application) generates a random code_verifier and derives a code_challenge using a method (typically S256 = SHA-256). It then sends the code_challenge and method to the Authorization Server.

2. Authorization Server stores challenge and prompts login
The Authorization Server stores the code_challenge (along with the method) temporarily, linked to the authorization request. It then displays the login page to the user.

3. User authenticates and receives authorization code
After successful login, the Authorization Server redirects back to the SPA with an authorization code: http://{spa}/callback?code=AUTH_CODE

Note: This authorization_code is internally mapped to the stored code_challenge.

4. SPA exchanges code for tokens
The SPA sends the following to the token endpoint (/oauth/token):

authorization_code
code_verifier

5. Authorization Server verifies and issues tokens The Authorization Server:

Hashes the received code_verifier using the same method (S256)
Compares it with the stored code_challenge

✅ If they match, the server issues the tokens (e.g., access_token, optionally refresh_token)

⚡ Key Takeaway PKCE ensures that even if the authorization_code is intercepted, it cannot be exchanged for tokens without the original code_verifier.

Security Takeaways

PKCE is essential for securing SPAs. Since secrets cannot be safely stored in the frontend, PKCE ensures that only the original client can exchange the authorization code for tokens.

If you are using OAuth in your frontend application, implementing PKCE is a must

PHP vs Node.js Which One to Choose?

Suresh Ramakrishnan — Sun, 02 Nov 2025 10:54:17 +0000

Objective

In recent times, there’s been a noticeable industry shift toward Node.js for developing REST APIs, even though mature languages like Java, Python, and PHP already exist. This motivated me to evaluate Node.js performance against PHP, which is less commonly used in the industry today — even though many CMS platforms and web applications still rely on it.

Before choosing the right server-side scripting technology, I wanted to check how efficiently each one handles HTTP requests.

So, I decided to measure their real-world performance under load.

The goal was to find how Traditional PHP (with Apache), Modern Laravel Octane, and Node.js (with NestJS) behave under concurrent traffic.

But before diving into the results, let’s first understand how each of them processes requests.

PHP (with Apache HTTP Server)

Traditional PHP runs in a request-per-process model.
Each HTTP request spawns a new PHP process or thread under Apache’s mod_php module.
After execution, the process ends — meaning the entire runtime and application state are re-initialized for every request

Laravel Octane (with RoadRunner)

Laravel Octane introduces a persistent application server that keeps the Laravel app in memory between requests.

It uses *RoadRunner *(or Swoole) as the server, drastically reducing startup cost per request.

Node.js (NestJS Framework)

Node.js uses an event-driven, non-blocking I/O model.
It runs on a single thread but uses an event loop to handle thousands of concurrent connections efficiently without creating a new process per request.

Test Setup

API Endpoint: Get User Data(10 records)
Concurrent Users: 50 (VUs)
Duration: 10 seconds
Load Test Tool: k6 (Grafana)

Test Results

Framework / Stack	Requests Count	Mean Duration (ms)	P95 (ms)	P99 (ms)	Mean RPS	Max RPS
PHP + Apache	107	6096.39	15197.79	15548.40	6.68	8.0
Laravel Octane (RoadRunner)	2311	217.91	288.76	729.08	231.1	247.67
NestJS (Node.js)	5237	95.67	130.04	402.85	585.33	247.67

But with the above performance results in mind, should we choose Node.js for our next project?

No — not just based on that.

Let’s examine the nature of PHP and Node.js before making a decision.

Node.js, can handle a large number of concurrent requests efficiently because, when your code makes asynchronous I/O calls (such as database queries, file reads, or HTTP requests), Node.js delegates these operations to the background thread pool.
While those tasks are running in the background, the event loop continues processing new incoming requests — which makes Node.js highly performant for I/O-bound workloads.

PHP, on the other hand, works differently.
Each worker can serve only one request at a time.
A worker executes your PHP script from start to finish and remains blocked until all I/O operations (database, file, or HTTP) are completed.
This means concurrency in PHP depends on how many workers are configured

But what happens when the code involves heavy or complex logic?

Now, let’s consider what happens when your application contains heavy computation or complex logic — this is the crucial part when choosing the right technology.

Node.js:
If one request performs a CPU-heavy task (for example, complex calculations, image resizing, large loops, or encryption), the event loop becomes blocked.
During that time, other requests cannot be processed, which can slow down overall performance.

PHP:
Suppose you configure 4 workers — this allows 4 requests to be handled simultaneously.
If one worker is busy with a heavy task, the other 3 can still continue processing other requests.
Because each worker runs in its own isolated process, one slow request does not affect others.

Conclusion

I hope this explanation helps you understand the fundamental differences and guides you in choosing the right scripting language for your next project.

NGINX Proxying Requests from One Server to Another Server

Suresh Ramakrishnan — Mon, 10 Feb 2025 02:19:35 +0000

Description

This guide explains how to configure Nginx to forward requests from one server to another while maintaining the correct URL structure. It covers key concepts such as using proxy_pass, handling path modifications, and ensuring smooth request forwarding. Additionally, it highlights common pitfalls like incorrect trailing slashes and how to avoid them. By following this guide, you can efficiently set up a reverse proxy for static content, APIs, or any other resources across different servers.

Configuration Breakdown

location ~ ^/cdn {     
    set $backend https://cloud.cdn.com; 
    proxy_pass $backend;
}

How It Works

1. Matching Requests for /static

The location ~ ^/static block applies to any request where the path starts with /static.

The ~ indicates that a regular expression is used (^/static ensures it matches from the beginning of the path).

2. Setting a Backend Variable

set $backend https://cloud.cdn.com;

Defines a variable $backend with the value https://cloud.cdn.com.

This provides flexibility for modifying the backend dynamically in the future.

3. Proxying Requests

proxy_pass $backend;

This forwards requests matching /static to https://cloud.cdn.com.

Example:

Request: https://sitea.com/static/image.png

Proxies to: https://cloud.cdn.com/static/image.png

The response is then returned to the original client.

Possible Issues & Fixes

1. Missing Trailing Slash in proxy_pass

If proxy_pass is set to https://cloud.cdn.com without a trailing slash, it behaves as expected:

The request path remains unchanged.

Example:

Request: https://sitea.com/static/image.png

Proxies to: https://cloud.cdn.com/static/image.png(✅ Expected)

2. Adding a Trailing Slash (/) in proxy_pass

If proxy_pass is https://cloud.cdn.com/, Nginx replaces /static with /:

proxy_pass https://cloud.cdn.com/;

Example:

Request: https://sitea.com/static/image.png

Proxies to: https://cloud.cdn.com/image.png (🚫 Incorrect if /static/ is required)

Correct Approach (If /static Must Be Included)

If cloud.cdn.com expects /static in the request, ensure:

proxy_pass https://cloud.cdn.com;

This keeps /static in the proxied request.

If cloud.cdn.com does not need /static, use:

proxy_pass https://cloud.cdn.com/;

This strips /static before forwarding.

Summary

Matches any request starting with /static.

Proxies to https://cloud.cdn.com.

Ensure correct trailing slash usage in proxy_pass to maintain the intended request path.