The problem: one dashboard, several very different users
An Aliste enterprise account isn't used by one person. A co-living operator or commercial landlord typically has an owner who needs the full picture, a facility manager who needs to see usage and respond to alerts, an accountant who needs billing data and nothing else, and front-desk or support staff who need to help tenants without touching payment settings or automation schedules. Handing all of them the same login solves the immediate access problem and creates several worse ones: no one can tell which person actually made a change, revoking one person's access means resetting a password everyone else also uses, and every user has far more reach than their job requires.
OAuth2, briefly: proving who you are without handing out your password
OAuth2 is the standard way a dashboard verifies a user's identity and grants access without the underlying systems ever having to trust a raw password on every request. Instead of re-checking a password on every action, the user authenticates once and receives an access token - a signed, time-limited credential the dashboard presents on every subsequent request. The token can carry claims about the user, including their role, and it can be revoked or left to expire without touching anyone else's session.
RBAC, briefly: bundling permissions into roles instead of granting them one by one
Role-based access control is the other half of the picture. Rather than deciding, user by user, exactly which actions each person can take, RBAC groups permissions into roles - Owner, Facility Manager, Accountant, Tenant - and assigns each user to a role. Adding a new facility manager means assigning an existing role, not re-deriving a custom permission set from scratch, and it means every "Facility Manager" across every property gets the same, deliberately scoped set of capabilities.
How the two combine on every request
OAuth2 answers "who is this." RBAC answers "what are they allowed to do." Together, every API call a dashboard makes carries a token that identifies the user and their role, and the server checks that role against what the specific action requires before doing anything - reading usage data, updating a billing record, changing an automation schedule, inviting a new user. Critically, this check happens on the server, not just in what buttons the interface shows: hiding a "Manage Billing" button from a Facility Manager's screen means nothing if the underlying API would still process that request from their token. Real enforcement has to reject the request itself, regardless of what the interface displays.
Why this matters more, not less, at enterprise scale
The bigger a customer's footprint, the more this compounds. A facilities company managing dozens of properties for different owners has many more people who need some access and even more reasons no one of them should have all of it. RBAC keeps a support agent from ever being able to reach a payment setting they never needed, and OAuth2 means that when someone leaves the company, disabling their account is the entire offboarding process - no shared password to rotate, no other user's session affected. Every action is also attributable to a specific token and therefore a specific person, which matters as much for accountability as it does for security.
What "basic requirement" actually means here
None of this is exotic - OAuth2 and RBAC are the same baseline pattern used by any serious enterprise software, not a smart-metering-specific idea. That's precisely why their absence is a red flag rather than their presence being a selling point: a dashboard handling electricity billing and building automation for an enterprise customer without token-based auth and role-scoped permissions is missing a baseline any procurement or security review would expect to find. Building it in from the start is what lets Aliste hand an owner, a facility manager, an accountant and a support team the same dashboard without any of them being able to do more than their role should allow.
Frequently asked questions
Isn't a single admin login enough for a small property?
It might work at very small scale, but it breaks down fast: every person who needs any access shares one password, nothing is attributable to an individual, and revoking one person's access means changing the password for everyone. OAuth2 and RBAC scale down fine too - a one-person account is just a single user with the Owner role.
What's the difference between OAuth2 and RBAC?
OAuth2 is how a user proves who they are and gets a token to act on the system, without the dashboard or API ever seeing their password directly. RBAC is what happens after that: the token carries a role, and every action is checked against what that role is permitted to do. One answers "who is this," the other answers "what are they allowed to do."
Can permissions be enforced only in the dashboard's user interface?
No - hiding a button in the interface doesn't stop a request to the underlying API. Real enforcement has to happen server-side: every API call checks the caller's role against what that endpoint requires, regardless of what the interface shows or hides.
What happens when an employee with dashboard access leaves the company?
Their account is deactivated and their tokens stop being honored - nothing else needs to change. Because access was never a shared password, no other user's login is affected, and there's no shared secret to rotate.
Evaluating Aliste for an enterprise rollout?
See how our platform scopes dashboard access by role, across owners, facility managers, accountants and support teams.
Talk to our team
