B2B SaaS authorization is more complex than “admins see everything; members can only view.” A real system must determine tenant membership, permitted action and resource, data and field scope, inheritance, expiration, and how every high-impact action is audited.
This guide covers product requirements and acceptance tests, not a substitute for security architecture review. Authentication answers who you are; authorization decides whether you may perform this action now. Hiding a button in the frontend is not server-side authorization.
Before drawing roles and permissions, use the B2B customer interview template and requirement evidence matrix to verify the actual responsibilities of buyers, administrators, end users, and auditors instead of mapping job titles directly to system roles.
1. Write an Authorization Sentence
Use one consistent form:
May Subject perform Action on Resource in Tenant under Context?
For example:
May an East Region sales manager export a masked list of customers owned by the manager's team inside tenant A?
The sentence includes:
- Subject: user, group, service account, or agent acting for a user.
- Tenant: customer organization or workspace.
- Resource: customer, contract, report, invoice, or setting.
- Action: read, create, update, delete, export, approve, or grant.
- Scope: own, team, department, region, selected object, or all.
- Context: time, device, network, resource state, and approval state.
NIST describes RBAC as managing permissions through roles, with core user-role and role-permission relations plus optional hierarchy and separation-of-duty constraints. See the NIST RBAC FAQ.
2. Tenant Isolation Comes Before Role
In a multi-tenant system, authorization begins at the tenant boundary. An administrator in tenant A cannot access tenant B merely because both use the same role name.
Baseline rules:
- Every tenant resource has a non-null tenant_id.
- The session has one explicit active tenant.
- The server derives tenant context from trusted identity rather than a client claim.
- Read and write paths both enforce tenant context.
- Cache, search, files, and asynchronous jobs preserve the same boundary.
- Platform support access is separate from customer administration and audited independently.
AWS's prescriptive guidance models policy decision and policy enforcement points for multi-tenant authorization and includes RBAC and ABAC options: SaaS multi-tenant authorization design models.
3. Split “Menu Permission” into Four Layers
Feature and page
Can the user enter customer management, contracts, billing, or organization settings? This controls navigation and discoverability; it cannot be the only security check.
Action
Define atomic actions:
customer.read customer.create customer.update customer.delete customer.export customer.assign
Avoid one broad customer.manage permission that combines editing, deletion, export, and ownership transfer.
Data scope
Two roles with customer.read may have different visibility:
- Records owned by the user.
- User and direct reports.
- Team.
- Named department or region.
- Objects shared through a relationship.
- Entire active tenant.
Field and sensitive operation
Phone, national ID, cost, salary, or contract value may require masking, separate permission, or confirmation. Field visibility, field editing, and bulk export are distinct rights.
4. Start with Minimal RBAC
Use roles to group stable job responsibilities:
| Role | Customer read | Customer edit | Export | Billing | Grant access |
|---|---|---|---|---|---|
| Sales rep | Own | Own | No | No | No |
| Sales manager | Team | Team | Approval | No | No |
| Finance | Contract-related | No | Financial fields | Read | No |
| Tenant admin | Tenant | Tenant | Yes | Manage | Yes |
Built-in roles reduce setup effort; custom roles handle customer variation. Avoid one-off roles named after individual employees because role inventory quickly becomes unmanageable.
When attributes or relationships are needed
Extend beyond RBAC when a rule cannot be expressed cleanly:
- Edit only when a contract is in draft.
- Read only when resource region matches user region.
- A temporary project member has access until an expiration date.
- A document owner can invite named collaborators.
- A high-value refund requires an approver different from the requester.
These use resource attributes, environmental attributes, object relationships, and separation of duties. Increased flexibility requires an explainable “effective access” preview and automated tests rather than scattered page conditions.
5. Default Deny and Least Privilege
OWASP's authorization guidance recommends least privilege, deny by default, permission validation on every request, appropriate logging, and automated tests. See the Authorization Cheat Sheet.
Translate this into product rules:
- A new feature or resource is inaccessible until explicitly governed.
- A user receives only the access needed for current responsibilities.
- UI, API, export, batch job, and static resource enforce consistent rules.
- Guessing an object ID never grants access.
- Authentication does not bypass authorization for a high-impact action.
- Denial fails safely without revealing whether a protected object exists.
6. Administration Workflow
The admin experience should support:
- Viewing built-in and custom roles.
- Creating a role from atomic permissions.
- Configuring data and field scope.
- Assigning roles to users or groups.
- Previewing one user's effective permissions.
- Explaining source, inheritance, and conflict.
- Requiring approval or confirmation for high-risk grants.
- Expiration for temporary access.
- Before-and-after diff with audit history.
- Revocation with session, token, and cache invalidation.
Conflict behavior must be explicit
Do not silently use “most permissive wins.” Explicit deny, tenant boundary, compliance restrictions, and separation of duties should override ordinary allow. Document:
- Whether multiple roles form a union or support deny.
- Whether direct grants override roles.
- How data scopes combine.
- How role hierarchy inherits.
- When a change becomes effective.
- How old sessions and download links expire.
7. Hypothetical Case: CRM Discount Approval
This is an instructional scenario, not a real customer configuration.
Requirement: A salesperson creates a discount request. A regional manager approves up to 20%. Above 20% requires finance. A requester cannot be the final approver.
| Subject | Resource | Action | Scope | Constraint |
|---|---|---|---|---|
| Sales rep | discount_request | create/read | Own | Cannot approve |
| Regional manager | discount_request | read/approve | Region | ≤20%, not own request |
| Finance | discount_request | read/approve | Tenant | >20%, not own request |
| Auditor | discount_request | read | Tenant | Read-only, masked fields |
Negative cases to test
- A salesperson changes request parameters and calls the approval API.
- Region A manager supplies a Region B request ID.
- A manager approves their own request.
- A 19% request becomes 25% and reuses old approval.
- A removed role continues through an old page or token.
- Tenant A export reads a tenant B cache entry.
- An auditor bypasses field masking through bulk export.
Authorization acceptance must cover hostile and accidental paths, not only happy paths.
8. Member Lifecycle
- Validate tenant, email, and default role before invitation.
- Use job templates for onboarding instead of copying an old employee's access.
- Remove prior responsibility before granting a new one on transfer.
- Give temporary project access an owner and expiration.
- Revoke sessions, tokens, API keys, and shared links on offboarding.
- Ask customer administrators to recertify high-risk and unused grants.
Service accounts and agents should not inherit a user's full authority. Grant task-specific, short-lived, narrowly scoped capability and audit the actor, authorizer, and tool call. For operating guardrails, see AI agent product metrics.
9. Audit Log Requirements
Record:
- Actor and tenant.
- On whose behalf or through which service.
- Resource and action.
- Authorization decision and policy version.
- Time, source, and related task_id.
- Before-and-after summary.
- Approval, confirmation, and failure reason.
- Rollback and final state.
Audit data is sensitive too. Apply access control, retention, and tamper-resistance requirements.
10. Pre-Launch Test Matrix
- No role, expired role, and unknown permission deny by default.
- Same role cannot cross tenants.
- Hidden UI and API enforcement agree.
- Read, update, delete, and export are tested separately.
- Own, team, department, and tenant scopes are tested.
- Search and export cannot bypass field masking.
- Inheritance, conflict, and separation of duties match documentation.
- Revocation invalidates sessions, caches, and pending jobs.
- High-impact actions have confirmation, approval, and audit.
- Denial does not disclose protected resource information.
Continue with the B2B product manager role guide, B2B SaaS design project, or the B2B PM topic.