Building a Zero-Trust Network Access Proxy with Mutual TLS and JWT Authentication By Chidananda B V
Building a Zero-Trust Network Access Proxy with Mutual TLS and JWT Authentication
By Chidananda B V
Introduction
For my MCA (Cyber Security) major project, I focused on addressing a critical security challenge that continues to affect organizations globally.
Many enterprises still depend on the conventional perimeter-based security model, which assumes that users become trustworthy once they authenticate or gain internal network access. Although this approach served its purpose in earlier times, it proves inadequate against contemporary cyber threats including credential theft, malicious insiders, device compromise, and horizontal movement across networks.
To tackle this issue, I developed and deployed a Zero-Trust Network Access Proxy that performs continuous verification of both the user and device before granting resource access.
This implementation adheres to the foundational Zero Trust philosophy:
Never Trust. Always Verify.
The Problem
Conventional security approaches assume that all activity within corporate networks is inherently trustworthy.
This assumption introduces several vulnerabilities:
Compromised login credentials enable attackers to gain unrestricted system access.
Infected devices receive the same trust level as secure machines.
Authentication typically occurs only during the initial login session.
Users commonly receive excessive network permissions beyond their actual requirements.
Attackers can navigate freely between systems without triggering alerts.
The fundamental flaw in perimeter-based security lies in granting trust prematurely and maintaining it excessively.
My goal was to develop a system that independently validates each request, irrespective of its origin point.
Project Objective
This project aimed to create a lightweight Zero Trust gateway that enforces multiple security verification layers before routing requests to backend services.
The system validates:
Device Identity
User Identity
User Authorization
Access is permitted only after successful completion of all three verification stages.
System Architecture
The project comprises four Docker containers operating in concert.
1. Keycloak
Keycloak functions as the Identity Provider.
Its primary responsibilities include:
Handling user authentication
Generating JWT tokens
Managing public keys via JWKS
Overseeing identity administration
2. Zero-Trust Proxy
This component represents the project's core functionality.
The proxy executes three distinct security verifications for each incoming request:
Mutual TLS Authentication
JWT Validation
Role-Based Access Control Enforcement
Any verification failure results in immediate request rejection.
3. Secure File Server
The backend file server stores protected data assets.
Unlike conventional architectures, this server maintains no public network accessibility.
Access is exclusively available through the Zero-Trust Proxy.
4. Client
The client authenticates through two mechanisms:
Client Certificate (mTLS)
JWT Bearer Token
Communication with the proxy is restricted to authorized devices with valid user credentials.
Security Pipeline
Every request undergoes the same systematic verification sequence.
text
Client
│
▼
Mutual TLS Verification
│
▼
JWT Validation
│
▼
Role-Based Access Control
│
▼
Secure File Server
This stratified methodology ensures security enforcement precedes backend application processing.
Security Layers
1. Mutual TLS (mTLS)
Standard HTTPS authenticates only the server side.
Mutual TLS authenticates both communicating parties:
Server
Client
The client must present a valid certificate signed by the trusted Certificate Authority.
Invalid or missing certificates cause TLS handshake failure before HTTP request processing commences.
This mechanism prevents unauthorized devices from establishing connections.
2. JWT Authentication
Following device verification, the proxy validates the user's JWT.
The validation process encompasses:
RSA signature verification
Token expiration checking
Issuer validation
JWKS-based public key retrieval
Key ID matching verification
Only authentic Keycloak-issued tokens receive acceptance.
3. Role-Based Access Control (RBAC)
Authentication alone fails to provide sufficient security.
Even authenticated users should access only resources matching their authorization levels.
The proxy extracts user roles from the JWT and compares them against defined access policies.
Unauthorized requests receive HTTP 403 Forbidden responses.
Docker-Based Architecture
Containerization represented a critical architectural decision.
Docker enabled independent component operation while maintaining communication through a private bridge network.
Benefits include:
Simplified deployment processes
Environment isolation
Deployment reproducibility
Streamlined development workflows
Enhanced scalability potential
The backend file server maintains isolation from external users.
Security Testing
To assess implementation effectiveness, I conducted six security test scenarios.
Test 1
Valid request configuration
Result:
Successful access granted.
Test 2
Client certificate omitted
Result:
TLS handshake rejection.
Test 3
JWT token missing
Result:
HTTP 401 Unauthorized response.
Test 4
JWT token tampered with
Result:
Signature validation failure detected.
Test 5
User role lacks authorization
Result:
HTTP 403 Forbidden response.
Test 6
User possesses authorized role
Result:
Successful access granted.
The project effectively blocked all unauthorized requests while permitting legitimate users to access approved resources.
Performance Analysis
Performance overhead represents a common concern with Zero Trust implementations.
I measured response times across different conditions.
Scenario Response Time
Direct backend ~4 ms
Through Zero-Trust Proxy ~24 ms
The additional security measures introduced approximately 20 milliseconds of overhead.
Given the multiple authentication and authorization layers, this overhead remains acceptable for enterprise environments.
Technologies Used
Go (Golang)
Docker
Docker Compose
Keycloak
OpenSSL
JWT (RS256)
Mutual TLS (mTLS)
JWKS
RBAC
Reverse Proxy
Zero Trust Architecture
What I Learned
This project provided practical exposure to numerous significant cybersecurity concepts.
Key topics explored include:
Zero Trust Architecture principles
Identity and Access Management systems
Public Key Infrastructure (PKI)
TLS and Mutual TLS implementation
JWT Authentication mechanisms
Role-Based Access Control
Reverse Proxy development
Docker Containerization
Secure Backend Architecture design
Beyond technical coding skills, this project demonstrated how multiple security controls can function collectively to establish stronger defenses.
Future Improvements
Several enhancements could elevate this project to enterprise readiness.
Potential improvements include:
Multi-Factor Authentication (MFA) integration
Single Sign-On (SSO) implementation
Open Policy Agent (OPA) integration for policy-based access
Audit logging with Elasticsearch
Grafana dashboard implementation
Kubernetes deployment support
Rate limiting implementation
Web Application Firewall integration
Automated certificate rotation
Distributed deployment capabilities
Conclusion
This project demonstrates that Zero Trust implementation doesn't necessitate expensive commercial solutions.
By combining Mutual TLS, JWT authentication, Role-Based Access Control, Docker, and Go, I constructed a lightweight Zero-Trust Network Access Proxy capable of protecting backend resources from unauthorized access attempts.
Every request undergoes verification, every identity receives validation, and every authorization decision undergoes enforcement before access approval.
For me, this project transcended academic requirements—it provided an opportunity to understand modern enterprise security architecture design and implementation. It enhanced both my software engineering capabilities and cybersecurity expertise while delivering hands-on experience with technologies widely employed in production environments.
If you're interested in examining the implementation, understanding the architecture, or contributing to the project, please visit the GitHub repository. Feedback and suggestions are always appreciated.

Comments
Post a Comment