group-telegram.com/gde_tz_utka/17
Last Update:
🔐 IAA: Идентификация, Аутентификация, Авторизация
Вы можете сходу объяснить, чем они отличаются?
Давайте разберём эти три кита безопасности на примере доступа в офис:
1️⃣ Идентификация: ваше имя на пропуске ("Меня зовут Алексей»).
Типичные способы:
● Логин
● email
● Номер телефона
2️⃣ Аутентификация: проверка пропуска ("Докажи, что пропуск твой, введи пин-код»).
Типичные способы:
● 🔑 Пароль
● 📱 Код по SMS или из приложения (2FA)
● 🧬 Биометрия - отпечаток, лицо
● 🔐 Вход через сторонний сервис (например, Google)
💬 Вход через Google - это тоже аутентификация, просто доверенная внешним провайдеру. Это называется SSO (Single Sign-On) и работает через протоколы OAuth2 / OpenID Connect.
3️⃣ Авторизация: допуск в определённые помещения ("Тебе можно в переговорку, но не в серверную»).
Как это работает:
● RBAC - доступ по ролям
● ABAC - сложные правила ("редактировать только свои отзывы")
💡 Почему это важно?
Представьте, что в системе:
● Нет идентификации - все пользователи "Анонимусы"
● Нет аутентификации - любой может назваться админом
● Нет авторизации - все могут всё (даже удалить базу).
🏦 Пример из банка
1. Идентификация: Ввод номера телефона (*"Это клиент +7XXX»*).
2. Аутентификация: Подтверждение SMS-кодом ("Докажи, что телефон твой»).
3. Авторизация: Проверка прав ("Можно ли этому клиенту перевод на 1 млн?»).
🧠 Что писать в ТЗ
● Способ входа (логин/пароль, соцсети, SSO)
● Где и как хранится сессия (cookie, localStorage, backend)
● Какой формат токена (JWT или нет)
● Как реализуется logout
● Кто управляет ролями и правами
● Как проверяются разрешения
● Нужно ли продлевать сессию
✏️ Пример для ТЗ
1. Способ входа
Пользователь входит в систему с помощью логина и пароля, указанных при регистрации.
● Поля для ввода: email и пароль
● Обязательная проверка: валидность email, минимальная длина пароля 8 символов.
● При успешной аутентификации пользователь получает access_token и refresh_token.
● Поддержка «запомнить меня» через галочку на форме (продлевает срок действия refresh_token).
●
2. Хранение сессии
● Access_token (JWT) хранится в httpOnly cookie, срок действия 15 минут.
● Refresh_token хранится также в httpOnly cookie, срок действия 7 дней.
● Дополнительные данные (например, роли) не хранятся на клиенте.
3. Формат токена
● Используется JWT (JSON Web Token)
● Алгоритм подписания: HS256
Пример payload:
{
"sub": "user_id",
"role": "admin",
"exp": 1633017600
}
4. Logout
● Выход из системы реализуется удалением всех cookie и токенов.
● На стороне сервера refresh_token инвалидируется.
● После logout все защищённые страницы становятся недоступны, даже если остался access_token.
5. Управление ролями и правами
● Роли хранятся в отдельной таблице в БД (таблица roles).
● Связь с пользователями через user_roles.
● Управление ролями осуществляется через админку, доступную только пользователям с ролью admin.
● Возможные роли: admin, manager, user.
6. Проверка разрешений
● Проверка прав доступа происходит на бэкенде:
API возвращает ошибку 403, если у пользователя нет доступа к ресурсу.
● На фронте:
Интерфейс скрывает элементы, к которым нет доступа, на основе роли пользователя.
● Пример:
Доступ к /admin/* разрешён только admin.
Доступ к /reports разрешён admin и manager.
7. Продление сессии
● При каждом запросе с истёкшим access_token, фронт получает ответ 401 и автоматически делает запрос на /auth/refresh.
● При успешном обновлении токена новый access_token сохраняется в cookie.
● Если и refresh_token истёк — пользователь переходит на страницу логина.
Вывод
● Идентификация - кто ты?
● Аутентификация - докажи это.
● Авторизация - что тебе можно?
Как внедрять:
1. Выбрать методы (логин/пароль + 2FA + JWT).
2. Описать требования (как в примерах выше).
3. Протестировать сценарии (вход, выход, смена ролей).
✏️ Участвую в конкурсе от @systems_education
#продолжи_мысль_SE #ясное_объяснение
BY Утиные истории
Warning: Undefined variable $i in /var/www/group-telegram/post.php on line 260
Share with your friend now:
group-telegram.com/gde_tz_utka/17