Чому “ролі” — це не просто поле role=admin
У кабінетах і B2B‑сервісах важливі не тільки ролі, а й права на конкретні об’єкти: хто може бачити рахунки, хто затверджує, хто має доступ до персональних даних.
1) RBAC + permissions
- RBAC: ролі (Owner, Manager, Accountant) як набір прав.
- Права краще моделювати як дія + ресурс (viewInvoice, editUser).
- Для B2B часто потрібен рівень організації/тенанта.
2) Object‑level access
Перевірка доступу має враховувати: чи належить об’єкт організації користувача, чи є він у команді/проекті, чи має делеговані права.
3) Аудит дій
- Логи аудиту: хто, що, коли, з якого IP/пристрою.
- Окремі події для критичних операцій: зміна ролей, платежі, експорт.
4) Сесії та безпека
- Ротація refresh‑токенів, можливість “вийти з усіх пристроїв”.
- 2FA для адмінів (за потреби).
- Rate limit на логін/відновлення пароля.
Підсумок
Кабінет стає безпечним і керованим, коли авторизація спроєктована як система правил (RBAC + object‑level), є аудит дій і контроль сесій.