Skip to content

CONCEPT Cited by 2 sources

Fine-grained authorization

What it is

Fine-grained authorization means deciding access at the level of individual resources, actions, and runtime context — not just at the level of roles or API endpoints. The decision considers combinations of:

  • Who (principal identity / role / group membership).
  • What (the specific resource, including its attributes).
  • Which action (not just the API method, but the semantic operation).
  • In what context (time of day, geographic location, transaction amount, session attributes, environmental factors).

Contrast with coarse-grained authorization — "anyone in role Admin can call any /admin/* endpoint" — which cannot express rules like "a payment initiator may see the Transfer button only when the account is BUSINESS, ACTIVE, and the transaction amount is under the user's per-day limit."

Why it matters

Fine-grained authorization is the natural response to three converging forces:

  • Regulated workloads (finance, healthcare, government) require per-resource, per-action, context-dependent policies auditable by regulators.
  • Multi-tenant SaaS requires strict tenant-boundary enforcement on every request, often with per-tenant customization of the authorization model.
  • Least-privileged access makes only-what-you-need enforceable when "what you need" is computable from attributes, not hardcoded from role names.

Production shape

Convera's implementation (Source: sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization) captures the standard modern shape:

  • Policy language: Cedar — declarative, attribute-aware, analyzable, combines RBAC / ABAC / ReBAC in one language.
  • Policy engine: AVP — managed Cedar runtime with IsAuthorized synchronous evaluation.
  • Enforcement point: Lambda authorizer in front of API Gateway, evaluating Cedar policies against a Cognito JWT.
  • Hot-path optimization: two-level cache (API Gateway authorizer-decision cache + app-level Cognito token cache) delivers submillisecond latency because AVP is only hit on cache miss.

Convera reports thousands of authz requests/sec at submillisecond latency and ~60% reduction in time spent on access management tasks.

Key decisions

  • Attribute sourcing. Where do the attributes used by policies come from? In Convera's shape, they come from the JWT (so they can't be spoofed by the client), populated at token-issue time by a pre-token-generation Lambda hook that reads from RDS / DynamoDB.
  • Evaluation co-location. The same policy gates both the UI affordance ("show the Transfer button") and the API call ("allow POST /transfer"). Skipping the API-side check on the assumption that the UI will be the only client is a canonical fine-grained-auth anti-pattern.
  • Second-pass re-verification at the data layer. In multi-tenant, the backend re-evaluates AVP with tenant_id context before hitting the database — bugs in any single layer can't leak across tenants.

Seen in

Last updated · 200 distilled / 1,178 read