Most teams treat identity as a gate: you're either in, or you're not. In practice, the systems that hold up under real usage treat it as a graph — a web of relationships between users, services, and resources, each with its own scope and lifetime.
Why this matters
When access is modeled as a graph instead of a gate:
- Permissions can be scoped narrowly, per relationship, instead of globally
- Revoking one connection doesn't require touching the whole system
- Audit trails become a natural byproduct instead of an afterthought
A simple example
user --> service A (read-only, 30 days)
user --> service B (read/write, until revoked)
Each edge in that graph carries its own policy. That's the shape we default to when we design IAM strategy for clients — whether we're working in Azure AD B2C, a custom claims-based system, or something in between.
If you're rethinking how access is modeled in your own systems, get in touch — this is the kind of problem we like digging into.