RBAC на практике: Внедрение безопасной авторизации для вашего приложения
Полное руководство по Управлению Доступом на Основе Ролей (RBAC): Овладейте проектированием прав доступа, управлением ролями и безопасной авторизацией с практической реализацией на примере CMS.
YijunDeveloper
Хватит тратить недели на аутентификацию пользователей
Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.
У вас возникают трудности с внедрением безопасной и масштабируемой системы авторизации для вашего приложения? Управление Доступом на Основе Ролей (RBAC) — это отраслевой стандарт для управления правами пользователей, но его правильная реализация может быть сложной задачей. В этом руководстве мы покажем вам, как построить надежную систему RBAC, используя пример реальной Системы Управления Контентом (CMS).
Следуя этому руководству, вы узнаете:
✨ Как разработать и внедрить детализированные права доступа, которые дают вам точный контроль
🔒 Лучшие практики организации прав доступа в значимые роли
👤 Методы эффективного управления владением ресурсами
🚀 Способы сделать вашу систему авторизации масштабируемой и поддерживаемой
💡 Практическая реализация на примере реальной CMS
Полный исходный код для этого руководства доступен на GitHub.
Управление Доступом на Основе Ролей — это не просто назначение прав пользователям. Это о создании структурированного подхода к авторизации, который балансирует между безопасностью и поддержкой.
Вы можете узнать больше о Что такое RBAC в Wiki по авторизации.
Вот ключевые принципы, которым мы будем следовать в нашей реализации:
Детализированные права предоставляют вам точный контроль над тем, что пользователи могут делать в вашей системе. Вместо широких уровней доступа, таких как "админ" или "пользователь", мы определяем конкретные действия, которые пользователи могут выполнять над ресурсами. Например:
read:articles - Просмотр любой статьи в системе
create:articles - Создание новых статей
update:articles - Изменение существующих статей
publish:articles - Изменение статуса публикации статей
Владение ресурсами — это фундаментальное понятие в дизайне авторизации нашего CMS. Пока RBAC определяет, какие действия могут выполнять разные роли, владение добавляет личностное измерение в контроль доступа:
Авторы автоматически имеют доступ к статьям, которые они создали
Эта естественная модель владения означает, что авторы всегда могут просматривать и редактировать своё содержание
Система проверяет как права роли ИЛИ владение при обработке операций со статьями
Например, даже без права update:articles, автор все ещё может редактировать свои собственные статьи
Такой дизайн сокращает необходимость в дополнительных правах роли, сохраняя при этом безопасность
Этот двухуровневый подход (роли + владение) создаёт более интуитивную и безопасную систему. Издатели и администраторы всё еще могут управлять всем содержанием с помощью своих прав роли, в то время как авторы сохраняют контроль над своей работой.
Прежде чем начать, вам нужно создать аккаунт в Logto Cloud, или вы также можете использовать самостоятельно развернутую версию Logto с помощью Logto OSS версии.
Но для этого руководства мы будем использовать Logto Cloud для простоты.
Теперь, когда мы настроили RBAC в Logto, мы можем приступить к его интеграции в наш фронтенд.
Сначала следуйте Logto Quick Starts, чтобы интегрировать Logto в ваше приложение.
В нашем примере мы используем React для демонстрации.
После того как вы настроили Logto в вашем приложении, нам нужно добавить конфигурации RBAC для работы Logto.
Не забудьте выйти и войти снова, чтобы это изменение вступило в силу, если вы уже вошли в систему.
Когда пользователь входит в систему с помощью Logto и запрашивает токен доступа для указанных выше ресурсов API, Logto добавит области (права), связанные с ролью пользователя, в токен доступа.
Вы можете использовать getAccessTokenClaims из useLogto hook для получения областей из токена доступа.
И вы можете использовать userScopes, чтобы проверить, есть ли у пользователя разрешение на доступ к ресурсу.
Сначала нам нужно добавить промежуточное ПО в бэкенде, чтобы проверять права пользователей, подтверждать, что пользователь вошёл в систему, и определять, есть ли у них необходимые права для доступа к определенным API.
Как вы видите, в этом промежуточном ПО мы проверяем, содержит ли запрос фронтенда действительный токен доступа и соответствует ли аудитория токена доступа ресурсу API, который мы создали в Logto Console.
Причина проверки ресурса API заключается в том, что наш ресурс API фактически представляет собой ресурсы нашего CMS-бэкенда, и все права на наш CMS связаны с этим ресурсом API.
Поскольку этот ресурс API представляет ресурсы CMS в Logto, в нашем фронтенд-коде мы включаем соответствующий токен доступа при выполнении запросов к API на бэкенде:
Теперь мы можем использовать промежуточное ПО requireAuth для защиты наших конечных точек API.
Для API, которые должны быть доступны только пользователям с определёнными правами, мы можем добавить ограничения непосредственно в промежуточное ПО. Например, API создания статьи должен быть доступен только пользователям с правом create:articles:
Для API, которые должны проверять как права, так и владение ресурсом, мы можем использовать функцию hasScopes. Например, в API списка статей пользователи с правом list:articles могут получать доступ ко всем статьям, в то время как авторы могут получать доступ только к своим статьям:
На данный момент мы завершили внедрение RBAC. Вы можете проверить полный исходный код, чтобы увидеть полную реализацию.
Теперь давайте протестируем нашу реализацию CMS RBAC с использованием трёх только что созданных пользователей.
Сначала давайте войдём в качестве Алекса и Чарльза и создадим несколько статей.
Поскольку Алекс имеет роль Админа, он может создавать, удалять, обновлять, публиковать и просматривать все статьи.
Чарльз, имея роль Автора, может только создавать свои собственные статьи и может только просматривать, обновлять и удалять статьи, которые ему принадлежат.
Боб, с ролью Издателя, может просматривать и публиковать все статьи, но не может их создавать, обновлять или удалять.
