Multi-Client Security: One Core, Different Rules

Most APIs serve a single type of client. But real-world products need more: a mobile app for customers, a web dashboard for administrators, a headless API for partners, and internal tools for operations. Each client has different security requirements, different data access patterns, and different threat models. Enravo Core was built to handle this from day one.

The Problem with One-Size-Fits-All Auth

Traditional API architectures apply the same authentication and authorization rules to every consumer. The mobile app and the admin dashboard use the same token format, the same rate limits, the same session rules. This creates a constant tension: make security tight enough for the admin panel, and the mobile app becomes unusable. Relax it for mobile, and the admin panel is under-protected.

Enravo Core's Client Model

In Enravo Core, every API consumer is a registered Client. Each client gets its own Client ID, credentials, and a complete security configuration. When a request arrives, the guard pipeline evaluates it against the rules of the specific client that made the request — not a global policy.

id: mobile_consumer
platform: android
login_roles: [customer]
attestation: play_integrity
pop_mode: required
device_limit: 3
device_overflow: replace
rate_limit:
  requests_per_minute: 60
  burst: 10
ip_allowlist: []  # open
endpoint_scopes:
  - "products/*"
  - "orders/*"
  - "profile/*"

id: admin_dashboard
platform: web
login_roles: [administrator, moderator]
attestation: none
pop_mode: optional
device_limit: 5
device_overflow: block
rate_limit:
  requests_per_minute: 120
  burst: 30
ip_allowlist:
  - "10.0.0.0/8"
endpoint_scopes:
  - "*"  # full access

The mobile consumer app can only authenticate users with the 'customer' role. Even if an admin's credentials are entered in the mobile app, the login will be rejected because the client's login_roles don't include 'administrator'. This is client-level enforcement — it happens before the user's credentials are even checked.

Per-Client Security Policies

• Attestation: Mobile clients require Play Integrity / App Attest. Web clients don't.
• PoP Mode: Mobile requires proof of possession on every request. Web makes it optional.
• Device Limits: Mobile allows 3 devices, admin allows 5, with different overflow behavior.
• Rate Limits: Different throughput limits per client type and endpoint.
• IP Allowlists: Admin restricted to internal network, mobile open to all.
• Endpoint Scopes: Each client sees only the endpoints it needs.

How It Works in the Guard Pipeline

When a request enters the guard pipeline, the first thing that happens is client identification. The X-Client-ID header tells the pipeline which set of rules to apply. From that point forward, every stage — JWT validation, device checks, PoP verification, ability checks, and policy enforcement — uses the client-specific configuration.

Centralized Management

Despite the per-client isolation, all clients are managed from a single admin interface. You can create new clients, adjust their policies, monitor their traffic, and revoke access — all in real-time. Adding a new platform (say, a POS terminal) means creating a new client configuration. No code changes, no deployment.

This is the architecture that powers Rakton's multi-channel operations: a single backend serving mobile apps, web dashboards, marketplace integrations, and POS terminals — each with its own security profile, all running on the same Enravo Core instance.

If your API serves multiple types of clients, you need per-client security policies. Not middleware hacks, not environment variables — a first-class client model where each consumer has its own identity, rules, and limits. That's what Enravo Core provides.