Briefing

Coarse‑Grained Authorization via Access Levels and JWT Bitmaps

security
by Akarshan Gandotra ·

Configure access_levels.json per service and ensure gateway consumes it via S3; keep JWT bitmap small.

What to do now

Deploy updated access_levels.json to S3 and refresh gateway to pick up new permissions.

Summary

The article explains a lightweight authorization model where roles are collections of coarse access levels, and endpoints declare which access levels are required. The Auth Service consumes an access_levels.json file shipped by each product service to a known S3 path; no gateway deploy is needed to update permissions. JWTs carry a compact bitmap of granted access levels and a registry version number. The gateway uses the bitmap when the registry version matches; otherwise it falls back to string matching. This design keeps token size small (down from ~3 KB) and allows rapid permission changes without redeploying the gateway. The CI/CD pipeline automatically uploads the updated JSON to S3 on merge, and the gateway refreshes on its next cycle.

This approach separates policy definition (by product teams) from enforcement (by the gateway), enabling auditability, rollback via git, and minimal operational risk. The article also highlights the importance of keeping the bitmap stable and versioned to avoid mismatches.

Overall, the strategy provides a scalable, maintainable authorization layer that can evolve with product changes while keeping the gateway stateless and fast.

Key changes

  • Define roles as collections of access levels
  • Store access_levels.json per service in S3
  • JWT carries bitmap of granted access levels
  • Gateway uses registry version to interpret bitmap
  • Fallback to string matching if versions differ
  • CI/CD publishes JSON to S3 on merge
  • Token size reduced from ~3 KB to smaller
  • Gateway refreshes without redeploy

Affects

wp-customers enterprise

Source angles · 7 perspectives

Dev.to (top)
Independent angle

Authorization at Scale: Access Levels, Roles, and Compact Decisions

Open
Dev.to (top)
Independent angle

Operating the gateway: logs, traces, health, and degraded mode

Open
Dev.to (top)
Independent angle

Inside the Auth Service: From Token Validator to Policy Decision Point

Open
Dev.to (top)
Independent angle

Why we built an Auth Gateway instead of putting auth in every service

Open
Dev.to (top)
Independent angle

Endpoint classification: OPEN, AUTHENTICATED, ACCESS_CONTROLLED

Open
Dev.to (top)
Independent angle

Auth Gateway Post‑Mortem: Lessons Learned and Best Practices

Open

Customer impact

Analyzing matches…

Ask about this story

Impact on an agency? Which customers? Compare historically Risks of waiting