ProxyAuth (Community Edition)

ProxyAuth secures backend APIs through a fast authentication gateway. It encrypts tokens using ChaCha20 + HMAC-SHA256, 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 100,000+ requests per second under load.

**Project based on a other personal project (evolution): rust_actixweb_token

Documentation

Views the documentation
Possible to contribute the documentation: ProxyAuth Docs ❤️

Automatic config/ Setup v0.5.4

If the required configuration files are missing, they will be automatically downloaded from this repository during initialization.

By default, the config is now in /etc/proxyauth, owned by the proxyauth user v0.5.6.

Execute proxyauth prepare to create the system user and set up the configuration directory.

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.

ProxyAuth Advantages

• Centralized access point
• Secure tokens using CHACHA20 (HMAC SHA-256 + 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

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.