Role-based access in your app: let power users manage their own users

It starts with one feature request: "Can I manage my team from inside the app?" A customer wants to see who in their organization is using your app, promote a colleague, or remove someone who left. It sounds small. Then you try to build it securely on mobile and discover that user management is one of the easiest places to open a serious hole.

This post is about role-based access on mobile: why it is trickier than a web admin panel, the mistake that hands admin powers to every device, and how to let trusted users manage their ownusers without exposing everyone else's.

The trap: a secret key in the app

The naive approach is to give the app a powerful server key so it can list and delete users. On mobile this is dangerous in a way it is not on a trusted server: anything shipped in the app binary can be extracted. A determined user can pull the key out of the bundle and now has the keys to your entire user base — every customer's users, not just their own.

The lesson we keep returning to: secret keys belong on servers, never in a client app. So how do you let a real user manage other users from the app without ever shipping a secret?

Roles, scoped to the right boundary

The clean model is role-based access tied to the authenticated user. Two roles cover most apps:

• Member. A normal user. Can manage their own account — including deleting it — and nothing else.
• Admin. A trusted user who can manage other users within a defined boundary: list them, change their role, remove them.

The crucial detail is the boundary. An admin should be able to manage users in theirproject or organization — not globally. The server must enforce that an admin's powers stop at the edge of their own tenant, every time, on every request.

Enforce on the server, every request

Client-side role checks are for hiding buttons, not for security. The actual rules live on the backend:

1. The request carries the user's session token (see session management).
2. The server resolves who they are and what role they hold — ideally checked fresh, so revoking admin takes effect immediately.
3. Every list/update/delete is authorized against that role and scoped to their tenant. A member trying to delete someone else gets a 403; an admin acting outside their boundary gets a 403.

Hiding the "Remove" button for members is good UX. Rejecting the request on the server is what actually keeps you safe.

Who grants admin?

A user must never be able to promote themselves. Admin assignment belongs to someone with more authority — typically the app owner from a dashboard, or an existing admin within the same boundary. That keeps privilege escalation off the table: the most a compromised member account can do is manage itself.

How Kembo does role-based access

This is exactly the model Kembo ships. End users have a role — member or admin — and it unlocks user management from inside your app without ever putting a secret key in the binary.

• You assign admin from the Kembo dashboard. The project owner promotes a trusted end user; the user cannot self-promote.
• Admins use ordinary SDK hooks — list users, change a role, remove a user — authorized by their own session, scoped to your project. Members calling the same hooks are rejected.
• Enforcement is server-side and checked fresh, so the role on the token can never be trusted past its actual permissions, and revoking admin takes effect right away.
• Members can still manage their own account, including deletion — covering the store deletion requirement for every user.

Power without the leak

Role-based access on mobile comes down to one discipline: never trust the client with authority. Define clear roles, scope admin powers to the right boundary, enforce every action on the server, and keep promotion in trusted hands. Do that and you can hand real user-management power to your customers without risking everyone else's data.

Want it without building the backend? Start a free Kembo project, assign an admin from the dashboard, and let trusted users manage their own team through the SDK — securely, by design. Next week we tie the whole series together: the mobile launch checklist, from prototype to production.