Role & Permission Capabilities (The Winning Factor)

Our newly refactored authentication and access control system moves beyond basic Role-Based Access Control (RBAC) into a hybrid Permission-Based Access Control (PBAC) system optimized for edge computing and enterprise B2B SaaS.

1. What are the Capabilities?

Decoupled Identity & Memberships

A User identity (email, password, SSO) is completely separate from a Tenant (workspace).

• Capability: A single user can belong to multiple workspaces with completely different permissions in each.
• Example: John is the Owner of "John's Agency" but a Viewer in "Client Project A". et

Granular Permission Resolution

Instead of microservices checking if (user.role === 'admin'), they check if (user.permissions.includes('blog:posts.write')).

• Capability: Roles (role_admin, role_member) act purely as templates that expand into an array of specific string permissions.
• Example (Cross-Service Control): If a user needs full access to the Blog but only view access to the Chatbot, their token simply carries permissions: ["blog:posts.read", "blog:posts.update", "chatbot:slots.read"].
  • The Blog Service sees blog:posts.update and allows edits.
  • The Chatbot Service looks for chatbot:slots.write, doesn't find it, and safely denies the action.

Asymmetric Edge Verification

Gateways and microservices don't query the database to check if a user is allowed to do something.

• Capability: The manager (Identity Provider) uses an RS256 Private Key to sign a JWT containing the user's exact permissions array for that specific tenant.
• Example: The API Gateway intercepts the request, uses the Public Key to instantly verify the signature, and forwards x-user-permissions to the downstream service. Zero database lookups.

2. What Can We Achieve With This?

Future-Proof "Custom Roles"

Because our microservices only look at standard permission strings (service:resource.action), we can easily introduce a "Custom Roles" feature for Enterprise pricing tiers. Tenants will be able to check boxes to create a role like "Content Editor" that only has ["blog:posts.read", "blog:posts.update"] but absolutely no ["settings:workspace.write"].

Strict Service Isolation (Paid Features)

We embed services: { blog: { enabled: true } } directly into the token. If an end-user tries to access a premium module the Workspace owner hasn't paid for, the API Gateway drops the request immediately at the edge.

Secure Inter-Service Communication (M2M)

Using the same infrastructure, microservices can authenticate with each other. The Media Service knows a request is legitimate because it trusts the RS256 signature produced by the Gateway or Manager.

3. Our Winning Factors (Competitive Advantage)

1. Enterprise-Ready from Day 1: Most startups build simple role: 'user' | 'admin' systems and have to perform brutal, multi-month rewrites when they land their first enterprise customer who demands custom roles. We have already bypassed this technical debt. We are built like GitHub or Stripe.
2. True Edge Performance: Database bottlenecks are the #1 cause of API latency. By pushing permission evaluation into the JWT and verifying it asymmetrically at the Cloudflare Worker/Gateway level, our routing overhead is practically <2ms.
3. Atomic Safety: By centralizing tenant and membership creation into atomic database transactions (e.g., buildNewTenantTransactionRecord), we guarantee that a user will never end up in a corrupted state where they are charged for a workspace but have no permissions to access it.