Authorization & Access Scopes
Authorization in Acceso is enforced using API key policy metadata. Clients do not manage roles. The gateway makes the allow/deny decision per request.
Scope model
Each API key is bound to a policy with explicit scope dimensions:
Allowed service domains
Enabled endpoint categories
Feature-level flags
Rate and usage limits
How authorization is evaluated
After authentication, the gateway evaluates policy rules against the request:
You can treat scopes as “what this key is allowed to call”. Rate limits are “how often it may call”.
Version + domain extracted from the path.
Endpoint category (for example: public data vs premium analytics).
Feature flags that gate pre-release APIs.
If any check fails, the request is rejected. The error is structured. It does not reveal internal policy configuration.
Multi-key strategy (recommended)
Prefer multiple narrow keys over one wide key:
Split keys by domain (
solana,defi,polymarket,zk).Split keys by workload (batch jobs vs interactive services).
Keep write-style scopes separate from read-style scopes.
Least privilege patterns
Use scopes to reduce blast radius:
Faster incident response. You revoke only what is affected.
Cleaner usage attribution. Quotas map to a specific system.
Safer rollouts. Enable new surfaces per key, not globally.
Guarantees
Authorization is centralized and infrastructure-driven.
Error responses do not reveal internal policy configuration.
Isolation is enforced per API key by default.
Scopes and features can be enabled incrementally per key.
Last updated