In an earlier PR, we submitted a report_usage callback and shared feedback about limitations of the current dbdriver model. The maintainer acknowledged the feedback and suggested opening a separate issue with more details — this is that issue.

The Problem

The current dbdriver interface (MySQL, PostgreSQL, Redis, etc.) is well-designed to cater wide audience but increasingly misaligned with modern deployment and security requirements:

1. External Dependencies & Build Overhead
   Linking against libmysqlclient, libpq, etc., complicates builds and increases maintenance overhead (tracking updates, patches, and adding new drivers). While the database interface is necessary for enterprise deployments, this can be addressed in a more universal and lightweight way.

2. Dynamic Username Generation
   Modern secure deployments often require dynamic usernames rather than static ones. For example, in the Mesibo TURN server, usernames are generated dynamically based on timestamp, user type, call ID, and other attributes to control per-session access. There is no way it can work with static database lookups.

3. Security & Privacy Risks
   To use database drivers, operators must either maintain a separate database specifically for Coturn or expose their production database to the TURN server. In both cases, credentials reside on the TURN host, creating an unacceptable attack surface. This is the most critical pushback we encountered with some of our on-premise customers, especially in regulated sectors such as finance, healthcare, and government, where security policies prohibit storing database or user credentials outside their servers.

Proposed Solution: REST API-Based Authentication & Reporting

We propose replacing the dbdriver model with a native REST API module. The implementation is lightweight and can largely reuse existing dbdriver logic with minimal code changes. Our REST implementation only uses two functions: get_user_key() and report_usage() from dbdriver. Many parts of turnadmin would no longer be required.

Allocation Request Flow

When a client requests an allocation, the TURN server makes an HTTP request to a configurable REST endpoint (from get_user_key()), passing the username and optionally the realm, client IP, or other metadata. Example:

{"id": 123, "auth": "<auth>", "turn": {"user": "<username>", "realm": "<realm>", "ip": "<client ip>"}}

REST Response

The REST service can either reject the request or respond with an HMAC key and optional attributes such as TTL:

{"hmac_key": "2b90c7626e37300fb07129c869e9d626", "ttl": 86400, "id": "123", "result": true}

The hmac_key is what Coturn needs, obtained without exposing any user credentials or database details.

Communication can be secured via IP whitelisting, JWT, or custom HTTP headers.

Configuration

Since each organization may have a different API format, both the endpoint and request body can be fully configurable in the Coturn config file:

rest_api_url = https://api.example.com/turn/auth
rest_api_body = {"id":%lld,"auth":"%s","turn":{"user":"%s","realm":"%s"}}

Advantages

• Lean & dependency-free -- no DB client libraries required in the build. Even a universal binary release can be built without those dependencies.
• Enhanced security -- credentials never touch the TURN server.
• Dynamic username support -- validation logic is fully independent of Coturn (time-based, call-ID-based, etc.).
• Easy integration -- most organizations already expose REST APIs.

Since we already deployed this REST API-based driver in mesibo's production environment, we will be happy to contribute our implementation if this aligns with Coturn's roadmap.