Вы можете сходу объяснить, чем они отличаются? Давайте разберём эти три кита безопасности на примере доступа в офис: 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. Протестировать сценарии (вход, выход, смена ролей).