Introducing EAP: The Production-Ready Zero-Config Auth Proxy with Cloud IAM & Rate Limiting

Securing web endpoints and service-to-service communication is notoriously complex. You often find yourself wrapping services with complex setups like oauth2-proxy, writing custom token exchangers, or writing redundant authentication logic across different service repositories.

To solve this, I built EAP—a lightweight, zero-config authentication proxy designed to handle modern, multi-cloud enterprise authentication out of the box.

With EAP, you can secure any backend service without writing a single line of auth code. Just run the Docker container, specify your environment variables, and get robust Google OAuth (U2S), JWT verification (S2S), Cloud Identity integration, and built-in rate limiting immediately.

💡 Key Features of EAP

• 🔒 Double Authentication Modes:
  
  
  
  
  • User-to-Server (U2S): Secure browser access using Google OAuth.
  
  
  • Server-to-Server (S2S): Validate server calls via JWT with custom key signature support (RSA).
  
  
  
  


• 👥 Domain & Email Whitelisting: Restrict user login access to specific domains or specific emails via ALLOWED_EMAILS.


• ☁️ Native Cloud Provider Integrations: Built-in hooks for cloud-specific authentication patterns:
  
  
  
  
  • GCP (GCP_ONLY)
  
  
  • AWS Cognito (AWS_ONLY, token exchange configs)
  
  
  • Azure AD (AZURE_ONLY, target resource mapping)
  
  
  • Kubernetes (KUBERNETES_ONLY)
  
  
  
  


• ⚡ Built-in Rate Limiting: Prevent DDoS attacks and abuse with fine-grained rate limiting for both standard users and server-to-server connections.

🚀 Quick Start (Get running in 1 minute)

Deploying EAP is as simple as running a single command.

Here is the complete configuration to launch EAP in front of your upstream backend:

docker run -d \

  -p 8080:8080 \

  -e PORT=8080 \

  -e TARGET_URL="https://your-backend-service.com" \

  -e JWT_SECRET="your-jwt-signing-secret-key" \

  -e GOOGLE_CLIENT_ID="your-google-client-id" \

  -e GOOGLE_CLIENT_SECRET="your-google-client-secret" \

  -e GOOGLE_REDIRECT_URL="https://your-domain.com/auth/callback" \

  -e ALLOWED_EMAILS="[email protected],@yourcompany.com" \

  -e RSA_PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----" \

  -e GCP_ONLY=false \

  -e AWS_ONLY=false \

  -e AWS_COGNITO_TOKEN_URL="https://your-cognito-domain.auth.us-east-1.amazoncognito.com/oauth2/token" \

  -e AWS_CLIENT_ID="your-cognito-client-id" \

  -e AWS_CLIENT_SECRET="your-cognito-client-secret" \

  -e AZURE_ONLY=false \

  -e AZURE_TARGET_RESOURCE="https://database.windows.net/" \

  -e KUBERNETES_ONLY=false \

  -e RATE_LIMIT_PER_SEC=3.0 \

  -e RATE_BURST=5.0 \

  -e S2S_RATE_LIMIT_PER_SEC=30.0 \

  -e S2S_RATE_BURST=100.0 \

  parth14854tiwari/eap:latest

🔍 How it Works Under the Hood

EAP acts as a reverse proxy sitting directly in front of your target API (TARGET_URL).

1. User Visits Service: If a user visits the URL via a browser, EAP checks for authentication. If unauthenticated, it initiates a Google OAuth flow. Upon successful authentication, it verifies their email against ALLOWED_EMAILS.


2. Service-to-Service Requests: When another backend calls your API, EAP intercepts the call, validates the JWT Bearer token using the JWT_SECRET (or RSA_PRIVATE_KEY if configured), and enforces rate-limiting boundaries.


3. Upstream Forwarding: Validated requests are passed through cleanly to TARGET_URL.

🤝 Open Source & Contributing

EAP is open-source and ready for production testing. We would love to hear your feedback, issues, and feature requests.

If you find EAP useful, please:

• Star the repository 🌟 on GitHub.


• Open issues for bugs, features, or ideas.


• Submit PRs to help us add support for additional OAuth providers (like GitHub or GitLab)!