RBAC & Permissions

Authentication tells the application who a user is.

Authorization determines what that user is allowed to do.

SaaSStinger Lite implements Role-Based Access Control (RBAC) to ensure every action is performed only by users with the appropriate permissions.

Rather than relying on a single role check, SaaSStinger Lite uses multiple security layers that work together to protect your application.

What You'll Learn

In this guide you'll learn:

• How RBAC works
• Available workspace roles
• How authorization is enforced
• The layered security model
• Best practices for extending permissions
• Common authorization mistakes

Authentication vs Authorization

These concepts are closely related but serve different purposes.

A user must first be authenticated before authorization can be evaluated.

Available Roles

Every membership has exactly one role.

OWNER

The workspace owner has complete administrative control.

Typical capabilities include:

• Manage workspace settings
• Invite members
• Change member roles
• Remove members
• Transfer ownership
• Delete the workspace

ADMIN

Administrators help manage the workspace.

Typical capabilities include:

• Invite members
• Manage projects
• Manage tasks
• Moderate collaboration

Administrative permissions are intentionally limited compared to the workspace owner.

MEMBER

Members collaborate inside the workspace.

Typical capabilities include:

• View assigned resources
• Create and update their work
• Participate in projects
• Collaborate with teammates

Members cannot perform administrative operations.

Layered Authorization

Authorization is enforced through multiple independent layers.

Browser
    │
    ▼
ProtectedRoute
    │
    ▼
WorkspaceGate
    │
    ▼
RoleGuard
    │
    ▼
Server Action
    │
    ▼
Firebase Admin SDK
    │
    ▼
Firestore Security Rules

Each layer protects the application from a different class of errors or attacks.

Architecture Note

SaaSStinger Lite intentionally avoids relying on client-side role checks alone.

Even if a malicious user bypasses the browser, server-side authorization and Firestore Security Rules continue to enforce access control.

ProtectedRoute

ProtectedRoute ensures that only authenticated users can access protected pages.

If authentication fails, the user is redirected to the appropriate authentication screen.

This is the first authorization boundary.

WorkspaceGate

Authentication alone is not enough.

WorkspaceGate verifies that:

• the user belongs to a workspace
• an active workspace exists
• the workspace context is valid

If these checks fail, the user cannot access workspace resources.

RoleGuard

RoleGuard performs role-specific authorization.

Examples include:

• Editing workspace settings
• Inviting members
• Removing users
• Managing administrative resources

Rather than scattering role checks throughout the application, SaaSStinger Lite centralizes authorization into reusable guards.

Server-Side Authorization

Every privileged Server Action verifies the authenticated user before executing business logic.

The server never trusts information supplied by the browser.

Typical flow:

Client Request
      │
      ▼
Authenticated User
      │
      ▼
Verify Membership
      │
      ▼
Verify Role
      │
      ▼
Execute Business Logic
      │
      ▼
Update Firestore

This prevents unauthorized requests from bypassing the user interface.

Firebase Admin SDK

Server-side authorization uses the Firebase Admin SDK to verify the authenticated user.

Because verification occurs on the server, identity cannot be forged by modifying browser requests.

The Admin SDK acts as the trusted source of identity for privileged operations.

Firestore Security Rules

Firestore Security Rules provide the final layer of protection.

Even after server-side authorization succeeds, Firestore evaluates every database request against its security rules.

This creates defense in depth.

If an application bug accidentally permits an invalid request, Firestore Security Rules still prevent unauthorized access.

Security Note

Authorization should never rely on a single security layer.

SaaSStinger Lite combines route guards, server-side verification, and Firestore Security Rules to reduce the impact of implementation mistakes.

Extending Permissions

When adding new features:

1. Determine which roles should have access.
2. Protect the page with the appropriate route guard.
3. Verify membership on the server.
4. Validate the user's role before performing business logic.
5. Ensure Firestore Security Rules reflect the same authorization model.

Keeping authorization consistent across all layers helps avoid privilege escalation.

Principle of Least Privilege

Users should receive only the permissions required to perform their work.

For example:

• Members should not manage workspace settings.
• Administrators should not transfer ownership unless explicitly allowed.
• Owner-only operations should remain restricted.

Granting fewer permissions reduces the potential impact of compromised accounts.

Common Authorization Flow

User Clicks Button
        │
        ▼
Protected Route
        │
        ▼
Workspace Validation
        │
        ▼
Role Validation
        │
        ▼
Server Verification
        │
        ▼
Firestore Authorization
        │
        ▼
Operation Completed

Common Mistakes

Trusting Client-Side Role Checks

Client-side checks improve the user experience but are not a security boundary.

Always repeat authorization on the server.

Hardcoding Permissions Everywhere

Avoid scattering role checks throughout your components.

Centralize authorization using reusable guards and server-side validation.

Confusing Authentication with Authorization

A signed-in user is not automatically authorized to perform administrative actions.

Authentication identifies the user.

Authorization evaluates their permissions.

Ignoring Firestore Security Rules

Firestore Security Rules should mirror your authorization model.

They remain the final protection for your data.

Best Practices

• Keep authorization logic centralized.
• Verify membership before evaluating roles.
• Use reusable route guards.
• Authorize privileged operations on the server.
• Keep Firestore Security Rules synchronized with your application logic.
• Follow the principle of least privilege.

Related Articles

• Authentication
• Members
• Workspaces
• Invitations
• Audit Logs

Next Steps

Now that you understand how authorization works, continue with Usage Tracking to learn how SaaSStinger Lite measures workspace activity and enforces plan limits.