Кейс: авторизация в мультиарендном SaaS
Вопрос
Вы проектируете авторизацию для B2B SaaS: организации, роли внутри организации, общий доступ к отдельным документам. Как устроите?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Арендатор из аутентифицированного контекста, обязательный фильтр в слое данных, RLS как второй слой
Роли внутри организации для функций (RBAC): владелец, админ, участник, гость
Права на объекты через связи или ACL: общий доступ к документу
Централизованная политика (сервис или библиотека), запрет по умолчанию
DTO для полей, отдельная авторизация админских функций
Аудит действий и тесты доступа между организациями
Что могут спросить следом
- Как проверять права в фоновых задачах и вебхуках?
- Что делать с поддержкой, которой нужен доступ к данным клиента?
Разбор
Образцовый ответ: «Слой арендатора самый важный: tenant берётся только из токена или сессии, слой доступа к данным добавляет фильтр автоматически, а в PostgreSQL включён Row-Level Security как страховка. Внутри организации роли для функций: владелец управляет биллингом, админ пользователями, участник работает с данными, гость только читает общее ему. Общий доступ к документам через связи: документ, пользователь, отношение, это удобно выразить в ReBAC-движке вроде OpenFGA. Все проверки через одну точку принятия решений с запретом по умолчанию. Поля на запись через DTO. Фоновые задачи и вебхуки несут контекст арендатора явно. Доступ поддержки только по заявке клиента, ограниченный по времени и с аудитом. И тесты, которые пытаются достать данные чужой организации каждым методом».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.