Zero Trust Authorization
Qpher follows the Zero Trust security principle: never trust, always verify. Every API request is independently authenticated and authorized. There is no concept of a "trusted" session or a request that gets a free pass because a previous request succeeded.
How It Works
After the API Gateway authenticates your request (validates your API key and resolves your tenant), it sends a policy evaluation request to the Policy Engine before forwarding your call to any backend service.
The 7-Stage Auth Pipeline
Every request passes through these stages sequentially. A failure at any stage stops the pipeline immediately.
| Stage | Purpose | On Failure |
|---|---|---|
| 1. Skip check | Allow health/metrics endpoints through without auth | -- |
| 2. Extract API key | Read the x-api-key header | 401 ERR_AUTH_001 |
| 3. Resolve tenant | Hash the key and look up the tenant in the database | 401 ERR_AUTH_001 |
| 4. Inject context | Attach X-Tenant-ID, X-Request-ID, X-API-Key-Version | -- |
| 5. Rate limit | Check per-tenant rate limits using Redis | 429 ERR_RATE_001 |
| 6. Policy check | Evaluate the request against the Policy Engine's rule chain | 403 ERR_POLICY_001 |
| 7. Route | Forward the request to the target backend service | -- |
Rule Chain Evaluation
The Policy Engine evaluates a chain of rules using a first-deny-wins strategy. Rules are checked in order. If any rule denies the request, evaluation stops and the request is rejected. If no rule denies it, the request is allowed.
Rule 1: Tenant Plan Restrictions
Each pricing plan has access to a different set of features. If your plan does not include the requested endpoint, the request is denied.
| Feature | Free | Starter | Growth | Pro | Enterprise |
|---|---|---|---|---|---|
| KEM encrypt/decrypt | Yes | Yes | Yes | Yes | Yes |
| Sign/verify | Yes | Yes | Yes | Yes | Yes |
| Key rotation | -- | Yes | Yes | Yes | Yes |
| API key rotation | -- | Yes | Yes | Yes | Yes |
| Deterministic KEM | -- | -- | -- | Yes | Yes |
| DELETE operations | -- | -- | -- | -- | Yes |
Rule 2: Quota Checks
Your plan defines monthly limits for API calls, API keys, and PQC keys. The Policy Engine checks these quotas in real time.
| Resource | Free | Starter | Growth | Pro | Enterprise |
|---|---|---|---|---|---|
| API calls/month | 5,000 | 10,000 | 30,000 | 100,000 | 250,000+ |
| Active API keys | 1 | 3 | 5 | 10 | Unlimited |
| PQC keys per algorithm | 1 | 3 | 5 | 10 | Unlimited |
If you exceed a quota, the Policy Engine returns 403 ERR_POLICY_001 with a message
indicating which limit was reached.
Rule 3: Endpoint Rules
Additional endpoint-specific restrictions that apply regardless of quotas (for example, method-level restrictions or temporary blocks).
You can view your current usage and remaining quota on the Dashboard in the User Portal at portal.qpher.ai/dashboard.
Fail-Closed
If the Policy Engine is unavailable (network issue, service restart, crash), the API Gateway denies all requests rather than allowing them through.
| Fail Mode | Behavior | When Used |
|---|---|---|
| Closed (default) | Deny all requests if Policy Engine is down | Production |
| Open | Allow all requests if Policy Engine is down | Emergency debugging only |
Fail-open would mean that a Policy Engine outage silently removes all access controls. An attacker who can take down the Policy Engine would gain unrestricted access. Fail-closed trades brief availability loss for continuous security enforcement.
This design choice means that a temporary Policy Engine outage may block your API calls for a few seconds. Qpher's monitoring detects these situations and triggers automatic recovery. You can check real-time status at status.qpher.ai.
Per-Request, Not Per-Session
Traditional web applications often check permissions once at login and then trust the session. Qpher does not do this. Every single API call is independently evaluated:
- Your plan could change between two requests (for example, an upgrade or downgrade).
- Your quota could be exhausted mid-session.
- A new access rule could be deployed without restarting services.
This means the authorization decision is always based on the current state of your tenant, plan, and quotas -- not on a cached decision from a previous request.