Zero Trust Authorization
Qpher follows the Zero Trust security principle: never trust, always verify. Every API request carries its API key and passes the gateway pipeline. The gateway reuses an API-key lookup, and an allowed policy decision, for at most 10 seconds; there is no longer-lived session.
How It Works
After the API Gateway authenticates your request (validates your API key and resolves your tenant), it asks the Policy Engine to evaluate the request (or reuses an allowed decision from the last 10 seconds) before forwarding your call to any backend service.
The 7-Stage Auth Pipeline
Every API request passes through these stages sequentially. A failure at any stage stops the pipeline immediately.
| Stage | Purpose | On Failure |
|---|---|---|
| 1. Skip check | Let the health endpoint, public sign-in and sign-up endpoints, and webhooks (verified separately) through without API-key authentication | -- |
| 2. Extract API key | Read the x-api-key header | 401 ERR_AUTH_001 |
| 3. Resolve tenant | Hash the key and resolve its tenant through the Tenant Service (cached for up to 10 seconds) | 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_LIMIT_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 plan includes a set of operations and algorithms. If your plan does not include the one you request, the request is denied with 403 ERR_POLICY_001. What each plan includes: qpher.ai/plans.
Rule 2: Method Rules
Some HTTP methods are restricted by plan (for example, DELETE).
Rule 3: Usage Limits (checked last)
Each encrypt, decrypt, sign or verify call counts toward your plan's monthly usage. Limits are on qpher.ai/plans. The Policy Engine checks usage limits after every other rule, so a request another rule denies does not count. A request over a limit is denied with 403 ERR_POLICY_001.
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 Policy Engine outage blocks your API calls until the Policy Engine is back.
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 takes effect when the Policy Engine is redeployed; no other service has to change.
The gateway reuses an API-key lookup, and an allowed policy decision for the same endpoint, for at most 10 seconds, and the Policy Engine reuses a tenant's plan for a few seconds; a denial is never reused. A plan change, a revoked API key or an exhausted limit therefore takes effect within seconds.