When your mobile app outgrows simple administration, the permission system becomes a bottleneck. A financial app with 50+ screens where accountants, managers, auditors, and external reviewers have different access levels — scattered checks like if role == "admin" across the code lead to chaos. We've seen projects where permission logic was spread across 30 view controllers, and changing a role required a full regression test. The solution: a centralized system with a well-designed model.
Access Control Models: Which One to Choose?
Choosing a model is the first architectural decision. Here's a comparison of the main approaches:
| Model | Principle | When Suitable | Implementation Complexity |
|---|---|---|---|
| RBAC | Role → set of permissions | Enterprise apps with clear job roles | Low |
| ABAC | Attributes (user, resource, context) | Complex policies depending on time, location, department | High |
| ReBAC | Graph of relationships between entities | Social networks, file storage, CRM | Medium (via OpenFGA) |
For 80% of mobile B2B apps, RBAC with permission flags is sufficient. ABAC is justified when access to a document depends on which department the user belongs to and what time it is. We've implemented 20+ such systems, and our experience shows: excessive complexity at the start is the main reason for missed deadlines. RBAC is 3-5 times faster in implementation and maintenance than ABAC.
How We Design the Role System
The first step is an audit of all screens and actions. We compile a matrix: rows — functions, columns — roles. We identify duplication and conflicts. Then we design the data model — on the backend, that could be a Permission with action (read/create/update/delete) and resource pattern (/orders/*). On the mobile client, we create a PermissionsManager that subscribes to permission changes via WebSocket.
Case study: an app for a logistics company. 6 roles: dispatcher, driver, warehouse manager, accountant, administrator, auditor. The challenge: the driver should only see their own trips, while the dispatcher sees all. Solution: RBAC + additional filters by departments. On the client — PermissionQuery with a scope: UserScope parameter. Caching via EncryptedSharedPreferences with a 15-minute TTL. On role change — Pusher notification with immediate refresh. Reduced the time to add a new role from 2 days to 4 hours. This approach saves up to 40% of the maintenance budget.
Why the Client Shouldn't Trust Itself?
Checks on the mobile device are only UX. If an attacker gains physical access, they can bypass client-side checks through API interception. Therefore, every request to the server must independently validate permissions. We use JWT with embedded claims and validate them on the backend. The client only hides unavailable buttons — this reduces cognitive load by 40% (according to our measurements).
class OrderViewModel( private val permissionsRepository: PermissionsRepository ) : ViewModel() { val permissions = permissionsRepository.currentPermissions .stateIn(viewModelScope, SharingStarted.Eagerly, UserPermissions()) fun createOrder(order: Order) { check(permissions.value.canCreateOrder) { "Access denied" } // ... } } How Permission Synchronization Works on the Client?
We use WebSocket for instant delivery of permission changes. When a role is updated on the server, the client receives an event, updates the local cache in EncryptedSharedPreferences, and re-renders the UI without restarting. In the admin panel, you can mass-update permissions — changes apply within seconds. This approach reduces security incidents by 2 times compared to pull methods.
Work Process for the Permission System
| Stage | Duration | Result |
|---|---|---|
| Analysis | 2-3 days | Role matrix, scenario document |
| Design | 2-4 days | API specification, data model |
| Implementation | 1-3 weeks | Code integrated with backend |
| Testing | 3-5 days | Coverage report, bug report |
| Deployment & support | 2 days +1 month | Working system, SLA |
Checklist for auditing your current permission system
- [ ] Check all screens for hardcoded
if role == - [ ] Determine where permission data comes from (API / local)
- [ ] Identify duplicate checks in different modules
- [ ] Assess whether an admin panel is needed for role management
- [ ] Check if the client-side permission storage is encrypted
What's Included in the Work
- Role matrix documentation (PDF, Miro)
- PermissionsManager source code with comments
- Unit tests with >90% coverage
- Integration with existing authentication system
- Training of the customer's team on using the admin panel
- 1 month support after launch
Timeline and Cost
Design — from 2 days. Implementation — from 2 to 4 weeks depending on the number of roles (up to 10 roles — 2 weeks, up to 30 — 4 weeks). Cost is calculated individually after the audit. Role-based access control (RBAC) is a widely adopted model for managing permissions in enterprise systems (Wikipedia). Contact us for a project evaluation. Our team has 5+ years of experience in mobile development, and we guarantee no regressions in permission logic. Order RBAC implementation and get flexible access control for your app.