Authentication & Rate Limiting
Relevant source files
The following files were used as context for generating this wiki page:
The Authentication & Rate Limiting systems protect the oxidize-server HTTP API by verifying caller identities and preventing resource exhaustion. These features function as Axum-based middleware that intercept requests before they reach the model runtime. The system supports API-key validation and token-bucket rate limiting to ensure stable, authorized access to local LLM inference services.
Sources: oxidize-server/src/AGENTS.md, README.md
Authentication Architecture
The authentication system validates API keys provided in incoming HTTP requests. You configure the required key via the OXIDIZE_API_KEY environment variable. The server supports two primary methods for passing the key: the x-api-key header or the Authorization: Bearer <key> header.
Sources: oxidize-server/src/auth.rs, README.md
Validation Process
The authentication middleware executes before rate limiting and route handling. It performs constant-time comparisons of the provided key against the expected value to prevent timing attacks. If the OXIDIZE_API_KEY environment variable is not set, the server allows unauthenticated access. Certain endpoints, such as /healthz, skip authentication checks to facilitate monitoring.
Sources: oxidize-server/src/auth.rs, oxidize-server/src/AGENTS.md, oxidize-golang/internal/auth/auth.go:14-22
The diagram shows the logic flow where internal health checks bypass security, while other paths require strict key verification if a key is configured.
Sources: oxidize-server/src/auth.rs, oxidize-golang/internal/auth/auth.go:14-36
Authentication Components
| Component | Responsibility | Source File |
|---|---|---|
OXIDIZE_API_KEY | Environment variable defining the required secret. | README.md |
auth.rs | Axum middleware implementation for key verification. | oxidize-server/src/auth.rs |
x-api-key | Custom HTTP header for providing the API key. | oxidize-server/src/auth.rs |
Authorization | Standard header using Bearer prefix for the API key. | oxidize-server/src/auth.rs |
Rate Limiting and Batching
Rate limiting prevents API abuse and manages the continuous batching wait queue. The implementation uses a token-bucket strategy to regulate request flow. In the C port, this is managed via an open-addressing table keyed by client IP. In the Rust server, the limits.rs module handles both rate enforcement and the queuing of requests for the generation loop.
Sources: oxidize-server/src/limits.rs, oxidize-c/include/oxidize/middleware.h:43-52
Middleware Stack Order
Middleware components are stacked in a specific sequence to optimize performance and security. Authentication occurs first to reject unauthorized traffic before it consumes rate-limiting or auditing resources.
The sequence illustrates the priority of authentication over rate limiting in the middleware chain.
Sources: oxidize-server/src/AGENTS.md, oxidize-c/include/oxidize/middleware.h:173-186
Rate Limiting Configuration (C Port)
| Parameter | Type | Description |
|---|---|---|
requests_per_minute | uint32_t | The steady-state refill rate of the token bucket. |
burst_size | uint32_t | The maximum number of tokens a bucket can hold. |
per_ip | bool | Toggles between individual IP tracking or a global limit. |
Sources: oxidize-c/include/oxidize/middleware.h:43-52
Implementation Details
Rust Server Logic
The oxidize-server implementation uses Axum middleware. The limits.rs file currently contains an anti-pattern using StdMutex in an async context, which is identified as a candidate for refactoring to tokio::sync::Mutex.
Sources: oxidize-server/src/AGENTS.md, oxidize-server/src/limits.rs
Go and C Port Parity
The project maintains authentication parity across ports. The Go implementation uses crypto/subtle.ConstantTimeCompare to ensure secure key validation, mirroring the Rust server's security standards. The C port defines a OcMiddleware struct that consolidates auth, rate limiting, and metrics.
Sources: oxidize-golang/internal/auth/auth.go:38-44, oxidize-c/include/oxidize/middleware.h:134-146
/* Authentication configuration in the C port */
typedef struct OcAuthConfig {
char *api_key; /* owned, NUL-terminated; NULL disables auth */
bool enabled;
} OcAuthConfig;
Sources: oxidize-c/include/oxidize/middleware.h:35-39
Conclusion
Authentication and rate limiting in oxidize provide the necessary security and stability for serving LLMs locally. By utilizing standard HTTP headers for authentication and token-bucket algorithms for rate control, the system ensures that inference resources remain available to authorized users while preventing service degradation from excessive requests.