Notifications
Clear all
Topic starter
06/06/2026 2:08 am
TL;DR: Authorization updates face a tradeoff between inline consistency and background reconciliation: synchronous updates can add about 50 to 150ms per membership change, while asynchronous updates create a stale-permissions window, according to WorkOS. Revocations are the harder case because delayed removal is a security exposure, not just a user-experience issue.
NHIMG editorial — based on content published by WorkOS: Synchronous vs. asynchronous authorization updates
By the numbers:
- For a single user with a handful of role assignments, synchronous authorization updates add roughly 50 to 150ms of extra latency depending on datastore and network topology.
- A group with 5,000 members and 5,000 role assignments means a reconciliation pass touches up to 25 million member-role pair evaluations.
Questions worth separating out
Q: How should security teams handle delayed revocation in authorization systems?
A: Treat delayed revocation as a security control failure, not a minor consistency issue.
Q: Why do asynchronous authorization updates create more risk than synchronous ones?
A: Asynchronous updates create a window where membership and effective permissions disagree.
Q: What breaks when authorization reconciliation is over-parallelised?
A: Over-parallelisation increases coordination complexity, partial-failure states, and retry ambiguity.
Practitioner guidance
- Set separate service-level targets for grants and revocations Measure grant propagation and revocation propagation independently, then make revocation the stricter path.
- Keep synchronous handling for high-risk revocations If you move low-risk grants to asynchronous processing, preserve synchronous removal for critical roles or require a much tighter reconciliation budget for those events.
- Instrument reconciliation lag and contention together Monitor p99 membership-change latency alongside write contention during reconciliation.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- How the team benchmarks inline permission-calculation latency across datastore and network conditions
- How one-job-per-group reconciliation is implemented for large membership sets
- How checkpointing and idempotency are used to recover from partial job failure
- How the fallback group-membership check works for high-stakes authorization flows
👉 Read WorkOS's analysis of synchronous and asynchronous authorization updates →
Authorization updates: when should teams move from sync to async?
Explore further
06/06/2026 3:37 am
Consistency timing is an authorization control decision, not a backend optimisation. When identity changes drive real access, the question is when the change becomes enforceable, not merely when it is written. That means authorization propagation belongs in the same risk conversation as recertification, revocation, and entitlement drift. Practitioners should treat update latency as part of the control surface, not a byproduct of implementation.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: How do you know if authorization propagation is actually working?
A: Watch for two signals: p99 latency on membership changes and the time it takes revoked access to disappear in practice. If either drifts upward, your effective permissions are no longer aligned with policy. For high-risk workflows, also test whether the application can verify current group state before allowing the action.
👉 Read our full editorial: Synchronous vs asynchronous authorization updates: choosing the right model
