CAuth

Central authentication, user accounts, usage accounting, and billing for the Adeno platform.

CAuth is the shared trust fabric for Adeno. Every service — Keryx, Kairos, Eunomia, APS, Arachne, and more — delegates login, account management, and billing to CAuth instead of implementing its own identity system.

• Host: https://adeno.ltd/cauth (also mounted on product domains as needed)
• Token model: JWT transtokens signed with CAUTH_SECRET_KEY (HS256)

Token model

Transtokens are JWTs with claims sub, iat, exp, type, and jti. Services validate them with the shared CAUTH_SECRET_KEY using HS256.

Authorization: Bearer <transtoken>

User-facing services obtain a transtoken via login or registration; internal services can also use shared secrets for backend-to-backend calls.

Security features

• Password hashing with PBKDF2-HMAC-SHA256
• Fernet encryption for server-side sensitive fields
• Itemized pricing support for downstream service usage

Core endpoints

All endpoints are JSON in / JSON out. Errors return an HTTP status code plus a body with an error key.

Authentication & accounts

Example:

curl -X POST https://adeno.ltd/cauth/auth \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com", "password": "..."}'

A successful response contains a token to attach to subsequent service calls:

{ "token": "<transtoken>", "uid": 123 }

Usage & credits

CAuth can authorize operations before they run; usage is priced per service-specific unit and billed through prepaid bundles or subscriptions.

Billing & subscriptions

API keys & services

The /cauth/service/verify endpoint is how downstream Adeno services validate tokens presented by clients without holding user context themselves.

Enterprise

Health

Email relay

Downstream services can send transactional email through CAuth's relay rather than holding SMTP credentials:

Integrating a service with CAuth

1. Register your service (POST /cauth/services/request) or seed it as an internal client.
2. Accept CAuth tokens from users: validate the JWT with CAUTH_SECRET_KEY (HS256), checking exp, type, and audience.
3. For backend validation of client-presented tokens, call POST /cauth/service/verify.
4. Before metered operations, call POST /cauth/account/usage/authorize; after completion call POST /cauth/account/usage/record with itemized units.
5. Propagate base URLs via environment variables (e.g., CAUTH_URL) pointing at the same external FQDN used by browsers.