Performance and scale
This page covers how authorization performs on SecureAuth Connect: where decisions are made, what contributes to latency, how caching works, and the trade-offs you make when you choose one enforcement point over another.
Where decisions are made
SecureAuth splits the authorization workload between two kinds of components:
- In-platform decisions run inside the SecureAuth authorization server as part of token issuance, consent, scope evaluation, dynamic scope evaluation, and RAR evaluation. These decisions happen once per token or consent event and are not on the per-request critical path.
- Runtime decisions run inside a SecureAuth authorizer at a gateway, service mesh, or standalone deployment. These decisions run on every request that reaches the authorizer and are on the per-request critical path.
Token-time decisions are amortized across the token's lifetime. A single evaluation produces a token that downstream services trust until expiration. Runtime decisions run per request, so latency budgets are tighter.
What contributes to latency
For any single decision, the latency budget is the sum of:
- Policy evaluation against the inputs the PDP already has in memory.
- Data lookups for identity attributes, token claims, and request context.
- External calls if the policy uses
http.sendin Rego or reads data that has not been pre-fetched. - Network hops between the enforcement point and the PDP, and between the PDP and its data sources.
Policy evaluation itself is typically negligible. The dominant contributors are external calls and, for distributed authorizers, network hops to fetch policy configuration or sync API definitions.
Keeping decisions fast
A few patterns consistently keep authorization latency low:
- Prefer token-time enrichment over runtime lookups. When data is stable enough to live in a token, inject it through a SecureAuth Extension so downstream policies read a claim instead of making an external call.
- Use dynamic scopes for per-resource checks. Dynamic scopes encode the resource identifier in the token, which lets the gateway make a local comparison instead of a graph lookup.
- Reach for FGA only when relationships must be evaluated per-request. When an object-level check is truly necessary, a Permission system call is the right answer. For coarse access, a token claim is faster.
- Avoid chained
http.sendcalls. Each external call adds end-to-end latency and a failure mode. Pre-fetch or pre-enrich when possible. - Co-locate the authorizer with the gateway. Running the authorizer in the same region and preferably the same cluster as the gateway keeps enforcement hops short.
Caching
SecureAuth caches at several layers. The exact cache durations depend on deployment and can be tuned per tenant, but the general shape is:
- Policy configuration. Authorizers fetch policy configuration from the authorization server and cache it. Updates propagate within the configured refresh interval.
- API definitions. Authorizers poll the gateway for API definitions so SecureAuth stays in sync with routing changes. Polling frequency is tunable.
- JWKS keys. The public keys used to verify tokens are cached by every authorizer and by downstream services.
- Decision results. Rego policies can use OPA's built-in caching for repeated evaluations, and external callouts can be wrapped in cached helpers.
Cache TTLs, poll intervals, and refresh windows depend on your deployment configuration. Confirm the live values with your platform operator or in the authorizer's configuration reference.
Token-time vs runtime trade-offs
| Dimension | Token-time enforcement | Runtime enforcement |
|---|---|---|
| When the decision runs | Once, at token issuance | Per request |
| Data freshness | As fresh as the token's TTL | As fresh as every call |
| Latency impact on the request path | None | On the critical path |
| Best for | Rules that change with the session | Rules that change with each request or object |
| Recovery UX | Decision surfaces in the auth flow, with MFA and consent available | Decision surfaces as a 4xx, without an authentication flow |
Most deployments combine both. Token-time sets the coarse decisions; runtime applies fine-grained ones.
Scaling the authorization server
The SecureAuth authorization server scales horizontally. Decisions are stateless beyond the configuration and identity data they reference, and identity and policy data are served from the platform's persistent store. Scale the authorization server along with the rest of the SecureAuth control plane.
Scaling runtime authorizers
Each authorizer scales with the gateway or mesh it protects. Because policy configuration is cached locally, a healthy authorizer does not need to call back to the authorization server on every request. Scale authorizers alongside the gateway, keep them co-located, and monitor cache hit rates and policy refresh lag.