ProxyAuth (Community Edition)

💣 ProxyAuth is now a universal reverse proxy system, capable of handling authentication and access control for any backend application or dashboard.

ProxyAuth secures backend APIs/Dashboard through a fast authentication gateway. It encrypts tokens using ChaCha20 + HMAC-BLAKE3, with config-defined secrets. It features built-in rate limiting (on proxy and auth routes) and uses Argon2 with auto-generated salts for secure password hashing. The service is extremely fast, handling ~ 180,000+ requests per second under load.

Documentation

Views the documentation
Possible to contribute the documentation: ProxyAuth Docs :heart:

Auto Salt config.json password for argon2

Please enter your password in config.json. The application will automatically generate the Argon2 salt on first startup and rewrite the file with the hashed password.

Rate Limiting

• Implements rate limiting per user rather than per token. This means that if someone generates 150 tokens and uses them simultaneously, the rate limit will still apply to the user, not to each token separately, unlike traditional systems. This mechanism applies to all routes managed by ProxyAuth.
• Adds rate limiting to the /auth route to help protect against brute-force attacks and excessive request traffic. The rate limiting behavior—such as request limits, configurable via the config.json file. This allows for dynamic adjustments without needing to modify the application code. The implementation uses a middleware layer that evaluates each incoming request to /auth and applies the configured limits accordingly.

ProxyAuth Usage

Configuration file

routes:
  - prefix: "/redoc"
    target: "http://127.0.0.1:8000/redoc"
    secure: false

  - prefix: "/api_test/openapi.json"
    target: "http://localhost:8000/api_test/openapi.json"
    secure: false

  - prefix: "/api_test"
    target: "http://localhost:8000/api_test"
    username: ["admin", "alice1", "alice15", "alice30"]
    proxy: true/false # --> configure proxy
    proxy_config: "http://myproxyurl:8888" # --> pass via proxy for call the target.
    cert: {"file": "certificat.pk12", "password": "1234"} # /!\ this fonctionnality is experimental untested version 0.5.0 /!\

{
  "token_expiry_seconds": 3600,
  "secret": "supersecretvalue",
  "host": "127.0.0.1",
  "port": 8080,
  log: {"type": "local"}, --> use for loki {"type": "loki", "host": "http://host_loki:port"}
  "ratelimit_proxy": {
    "burst": 100,
    "block_delay": 500,
    "requests_per_second": 10
  },
  "ratelimit_auth": {
    "burst": 10,
    "block_delay": 500,
    "requests_per_second": 10
  },
  "worker": 4,
  "users": [
    { "username": "admin", "password": "admin123" },
    { "username": "bob", "password": "bobpass" },
    { "username": "alice1", "password": "alicepass" }
  ]
}

curl -fsSL https://proxyauth.app/sh/install | bash

curl -fsSL https://proxyauth.app/sh/uninstall | bash

sudo systemd start proxyauth

docker compose build
docker compose up -d

volumes:
  - ./config/config.json:/app/config/config.json
  - ./config/routes.yml:/app/config/routes.yml

docker compose restart

TODO

• Log to stdout using tracing (Rust log lib) [still being deployed]
• Protect passwords config.json using Argon2. [Done v0.4.0]
• Add Loki integration with tracing [needs further exploration] [Done >=0.5.2]
• Add revoke token method. Bonus: multi-cluster via redis [Done v0.8.3]

ProxyAuth Advantages

• Centralized access point
• Secure tokens using CHACHA20 (HMAC BLAKE3 + ROTATE) just define the same secret across all instances to have the same token calculations (if use the same images).
• Semi-static tokens (refresh_token is only recalculated at intervals defined in the config)
• Tokens can be recalculated using a random exponential factor, allowing for further complexity.
• Possible send logs via loki [>=0.5.2]

Potential Disadvantages

• If someone can reverse-engineer the hash, they could potentially access services. This is why you must define a secure secret (over 64 characters!) in the config. This method is used in Django for password hashing via PBKDF2: https://docs.djangoproject.com/en/5.1/ref/settings/#std-setting-SECRET_KEY

Failover

Failover normal mode (click for open)

Failover over mode proxy (click for open)

ProxyAuth Structure

The server behaves like an authentication proxy.

Refresh token route:

sequenceDiagram
    autonumber
    participant C as Client
    participant P as ProxyAuth

    C->>+P: POST http://127.0.0.1:8080/auth<br>-H "Content-Type: application/json"<br>-d {"username": "user", "password": "pass"}
    P->>+P: Check credential
    P->>+C: return json format <br>{"expires_at":"2025-04-12 16:15:20","token":"4GJeCUwOzILd..."}

Scenario 1: Valid Token

sequenceDiagram
    autonumber
    participant C as Client
    participant P as ProxyAuth
    participant A as API/Service

    C->>+P: Send token Header <br> -X POST http://127.0.0.1:8080/api -H "Content-Type: application/json" <br>-H "Authorization: Bearer UmbC0ZgATdXE..." -d {"data": "test"}
    P->>+P: Check token send by client
    P->>+A: Forward original request <br> POST http://192.168.1.80/api_test <br>-H "Content-Type: application/json" <br>-d {"data": "test"}
    A-->>-P: Response
    P-->>-C: Response

Scenario 2: Invalid Token

sequenceDiagram
    autonumber
    participant C as Client
    participant P as ProxyAuth
    participant E as API/Service

    C->>+P: Send token Header<br> -H "Authorization: Bearer UmbC0ZgATdXE..."
    P->>+P: Check token send by client
    P-->>-C: Invalid Token
    Note over E: No external request made

This application allows applying global authentication tokens to any application, removing the need for them to implement token validation themselves, which simplifies future development.