Authentication

trojan-rs supports multiple authentication backends for verifying client passwords.

How Authentication Works

The Trojan protocol uses SHA-224 password hashing:

1. Passwords are configured in plaintext
2. At runtime, each password is hashed: hex(SHA224(password)) producing a 56-byte lowercase hex string
3. Clients send this hash in the Trojan header
4. The server compares the received hash against its set of valid hashes

In-Memory Backend

The simplest configuration. Passwords are listed directly in the config file:

[auth]
passwords = ["password1", "password2"]

Passwords can be reloaded via SIGHUP without restarting the server.

This backend has no traffic tracking or user management. For those features, use a SQL backend.

SQL Backends

SQL backends store users in a database with support for traffic limits, expiration, and quota management.

SQLite

# Initialize the database
trojan auth init --database sqlite://users.db

# Start server with SQL auth
trojan server -c config.toml --auth-database sqlite://users.db

PostgreSQL

trojan auth init --database postgres://user:pass@localhost/trojan

trojan server -c config.toml \
  --auth-database postgres://user:pass@localhost/trojan

MySQL

trojan auth init --database mysql://user:pass@localhost/trojan

trojan server -c config.toml \
  --auth-database mysql://user:pass@localhost/trojan

SQL Schema

The auth database tracks:

• Password hash — SHA-224 hex of the user's password
• Upload/download traffic — Bytes transferred
• Upload/download limits — Traffic quotas (0 = unlimited)
• Expiration — Optional account expiry timestamp
• Enabled status — Account active/disabled flag

When a user exceeds their traffic limit or their account expires, authentication is rejected.

HTTP Backend

The HTTP backend delegates authentication to a remote service via REST API. This is useful for centralized user management across multiple server nodes — a reference implementation is provided as a Cloudflare Worker (auth-worker).

[auth]
http_url = "https://your-auth-worker.workers.dev"
http_node_token = "your-node-token"

The server calls the remote service for every new connection:

1. POST /verify — sends the password hash, receives user status
2. POST /traffic — reports traffic bytes consumed

Both endpoints require the node token as a Bearer token in the Authorization header. The remote service tracks which node is making requests, records the node's IP, and maintains per-node traffic logs.

For a full deployment guide, see HTTP Auth Backend.

Reloadable Auth

The SQL auth backend supports periodic reloading. The server caches the valid password set and refreshes it at a configurable interval, so database changes take effect without restarting.

Choosing a Backend

Next Steps