Build vendor-neutral trusted proxy identity middleware for Python, Node.js, Rust, and Go

[horner]

Background

Many modern applications are deployed behind an identity-aware proxy, reverse proxy, gateway, ingress controller, or access layer that authenticates users before requests reach the application.

Examples include OAuth2 Proxy, Pomerium, Envoy ext_authz, Traefik ForwardAuth, NGINX auth_request, Cloudflare Access, and custom enterprise gateways.

These systems all support a similar architectural model:

User
↓
Authentication / access layer
↓
Application

The application should not need to own the login flow, session policy, MFA policy, or identity-provider integration. Those responsibilities belong to the upstream authentication layer.

However, the application still needs a secure way to consume the authenticated identity.

Problem

Today, teams often solve this in one of two ways:

1. They use vendor-specific middleware tied to a single access proxy or provider.
2. They write custom JWT/header validation logic inside each application.

Both approaches have drawbacks.

Vendor-specific libraries reduce portability. Custom application code leads to repeated implementations of the same security-sensitive logic: reading assertion headers, validating signatures, checking issuer/audience/expiration, mapping claims to users, and rejecting invalid requests.

The unsafe fallback is even worse: applications trust raw headers such as X-Forwarded-User, X-User, X-Email, or Remote-User without cryptographically proving that the identity was asserted by a trusted upstream component.

We need a small, boring, secure middleware layer that helps applications trust cryptographic assertions, not infrastructure brands.

Motivation

Build a vendor-neutral middleware family that lets applications accept identity from any trusted upstream component capable of sending a signed identity assertion.

The core idea:

Proxy authenticates the user
Proxy forwards a signed identity assertion
Application validates the assertion
Application receives verified user identity

This fills the gap between generic JWT libraries and full authentication frameworks.

Generic JWT libraries are flexible but too low-level for most app teams. Full authentication frameworks often assume the app owns the login flow. This project should sit between them: lightweight middleware for apps that delegate authentication to trusted infrastructure.

Goal

Create MVP middleware packages for:

• Python
• Node.js
• Rust
• Go

Each package should provide a framework-friendly way to:

• read a configured assertion header
• validate a signed JWT/JWS assertion
• verify issuer
• verify audience
• verify expiration
• resolve signing keys from JWKS
• expose verified identity to application code
• reject missing, expired, malformed, or invalid assertions
• avoid logging sensitive token material

The packages should be vendor-neutral and work with any identity-aware proxy, gateway, or auth service that can provide a signed assertion.

Non-goals

This project should not:

• implement a login flow
• replace OAuth/OIDC providers
• require Cloudflare, Pomerium, OAuth2 Proxy, Envoy, or any specific proxy
• manage browser sessions
• provide a full RBAC/ABAC authorization framework
• encourage trusting unsigned identity headers
• assume network location alone proves user identity

Suggested package names

Working names:

Node.js:
@mieweb/trusted-proxy-auth
Python:
trusted-proxy-auth
Rust:
trusted-proxy-auth
Go:
github.com/mieweb/trusted-proxy-auth-go

Names are not final.

Design principles

• Vendor-neutral by default.
• Secure defaults over convenience.
• Cryptographic verification before trust.
• Framework-native ergonomics.
• Minimal configuration.
• Clear failure behavior.
• No token leakage in logs.
• Portable across identity-aware proxies.
• Small enough to audit.

Guiding phrase:

Trust cryptographic assertions, not infrastructure brands.

MVP configuration model

Each implementation should support the same conceptual configuration:

TRUSTED_PROXY_ASSERTION_HEADER
TRUSTED_PROXY_JWKS_URL
TRUSTED_PROXY_ISSUER
TRUSTED_PROXY_AUDIENCE

Optional future configuration may include:

allowed algorithms
required claims
claim mapping
clock skew tolerance
JWKS cache policy
custom key resolver
custom error handler

Expected framework targets

Initial framework support should be practical, not exhaustive.

Suggested MVP targets:

Node.js:

• Express
• Fastify
• Hono
• Meteor accounts

Python:

• FastAPI / Starlette first
• Flask
• Django later

Rust:

• Axum first
• Actix Web later

Go:

• net/http first
• Chi/Gin adapters later if useful

Expected user-facing behavior

When an assertion is valid, application code should receive a verified identity object with at least:

subject / user id
email, if present
name, if present
raw verified claims

When an assertion is missing or invalid, middleware should reject the request with a clear 401 response.

When the assertion is valid but app-level authorization fails, that remains the application’s responsibility.

Documentation requirements

Docs should explain:

• what problem this middleware solves
• what it does not solve
• how identity-aware proxy authentication works
• why unsigned identity headers are dangerous
• how signed assertions improve the trust boundary
• how to configure the middleware
• how to use it with common frameworks
• how Cloudflare Access, Pomerium, OAuth2 Proxy, Envoy, NGINX auth_request, and custom gateways fit the general pattern

Cloudflare may be referenced as a familiar example, but not as the recommended or default approach.

Acceptance criteria

• Repository/package structure proposed for all four languages.
• MVP package implemented for at least one framework per language.
• Consistent configuration names and terminology across languages.
• Tests cover:
  • valid assertion
  • missing assertion
  • expired assertion
  • invalid signature
  • wrong issuer
  • wrong audience
  • malformed token
• Documentation includes vendor-neutral examples.
• Documentation clearly warns against trusting raw identity headers.
• Examples demonstrate the app receiving verified identity from middleware.
• No examples require a specific proxy vendor.
• Cloudflare is mentioned only as one example of the pattern.