Чем отличается авторизация от аутентификации?

Аутентификация vs Авторизация

Это две фундаментальные концепции безопасности, которые часто путают, но они решают совершенно разные задачи. Обе критичны для защиты системы, но на разных уровнях.

Что такое аутентификация (Authentication)?

Аутентификация — это процесс проверки идентичности пользователя. Ответ на вопрос: "Ты действительно тот, кем себя называешь?"

Суть: система проверяет что это именно тот человек, а не кто-то другой.

Примеры аутентификации:

• Вход в систему с логином и паролем
• Вход через Face ID на телефоне
• Ввод OTP (one-time password) отправленного на SMS
• Использование биометрии (отпечаток пальца)
• Магнитная карта на входе в офис

Что такое авторизация (Authorization)?

Авторизация — это процесс определения прав и разрешений пользователя. Ответ на вопрос: "Что этому пользователю разрешено делать?"

Суть: система проверяет что у пользователя есть право выполнить запрашиваемое действие.

Примеры авторизации:

• Администратор может удалить пользователя, обычный пользователь нет
• Модератор может блокировать посты, обычный пользователь нет
• Финансовый директор может утверждать бюджеты, менеджер нет
• Только владелец документа может его удалить

Сравнительная таблица

Архитектура: Как они работают вместе?

Пользователь                          Система
     ↓
1. Подает login/password ────────────→ [Аутентификация]
                                       Проверяем пароль в БД
                                       ↓
                                      ✓ Корректно?
                                      Создаем session/JWT token
                                       ↓
2. Получает токен ←────────────────── [Session создана]
     ↓
3. Запрашивает действие 
   (например, DELETE /users/123) ───→ [Авторизация]
                                       Проверяем:
                                       1. Токен валиден?
                                       2. У пользователя роль admin?
                                       3. У admin есть permission delete_user?
                                       ↓
                                      ✓ Разрешено?
     ↓
4. Получает результат ←──────────────  [Action выполнено]

Уровни безопасности

┌─────────────────────────────────────┐
│  Internet (незащищено)              │
├─────────────────────────────────────┤
│ Level 1: АУТЕНТИФИКАЦИЯ             │  ← Must login
│  - Проверка credentials             │
│  - Session/JWT token создается      │
├─────────────────────────────────────┤
│ Level 2: АВТОРИЗАЦИЯ                │  ← Role-based access
│  - Проверка ролей                  │
│  - Проверка разрешений             │
├─────────────────────────────────────┤
│ Level 3: Protected Resources        │  ← Данные
│  - Database                         │
│  - API endpoints                    │
└─────────────────────────────────────┘

Практические примеры

Пример 1: GitHub

Аутентификация:

Вводишь username/password
GitHub проверяет в БД
Даёт token доступа

Авторизация:

Ты можешь читать публичный repo (разрешено всем)
Ты НЕ можешь читать приватный repo чужого пользователя (нет permission)
Ты можешь удалять только СВОИ repo (owner check)

Пример 2: Google Workspace

Аутентификация:

Входишь через Google Account
Google проверяет пароль/биометрию
Отправляет authorization code

Авторизация:

Ты можешь читать свой Google Drive
Ты можешь редактировать документы в своей папке
Ты МОЖЕШЬ редактировать общие документы если тебе дали access
Ты НЕ можешь редактировать документы на которые нет прав

Модели авторизации

1. Role-Based Access Control (RBAC)

Роли: Admin, Manager, User

Admin ────→ [delete_user, edit_settings, view_reports]
Manager ──→ [edit_own_team, view_reports]
User ─────→ [edit_own_profile, view_public_data]

2. Attribute-Based Access Control (ABAC)

Решение основано на атрибутах:
- Роль: admin
- Отдел: Finance
- Время: 9:00-17:00
- IP: 192.168.1.0/24

Результат: Admin из Finance, в рабочее время, 
с офисного IP может смотреть финансовые отчеты

3. Access Control List (ACL)

Для конкретного ресурса указываешь кто может что:

Документ: "Annual Report 2024"
- Alice (owner): read, write, delete
- Bob (editor): read, write
- Carol (viewer): read

Технологии реализации

Аутентификация:

• HTTP Basic Auth (login:password в header)
• OAuth 2.0 (делегированная аутентификация)
• JWT (JSON Web Tokens)
• SAML (для enterprise)
• OpenID Connect
• Biometric (Face ID, fingerprint)
• TOTP/HOTP (двухфакторная аутентификация)

Авторизация:

• Session-based (проверяем роль в session)
• Token-based (роль в JWT payload)
• Policy engines (например, Casbin, OPA)
• Database queries (SELECT * FROM permissions WHERE user_id = ?)

Типичные уязвимости

Проблемы с аутентификацией: ❌ Слабые пароли ❌ Отсутствие двухфакторной аутентификации ❌ Утечка токенов в логах ❌ Истекший token не инвалидируется ❌ Сессия не удаляется при logout

Проблемы с авторизацией: ❌ Privilege escalation (пользователь становится админом) ❌ Горизонтальная эскалация (читаешь данные других пользователей) ❌ Missing authorization checks (забыли проверить разрешение) ❌ Неправильные роли (пользователю дали admin вместо user) ❌ No revocation (давал доступ, но забыл убрать)

Best Practices

Для аутентификации: ✅ Требуй сильные пароли + 2FA ✅ Используй HTTPS для передачи credentials ✅ Не храни пароли в plaintext (используй bcrypt/Argon2) ✅ Инвалидируй токены при logout ✅ Используй httpOnly cookies для токенов ✅ Логируй попытки входа

Для авторизации: ✅ Всегда проверяй права перед выполнением действия ✅ Используй least privilege principle — давай минимум прав ✅ Регулярно аудитируй права пользователей ✅ Логируй чувствительные операции ✅ Периодически пересматривай кто имеет какие роли ✅ Используй policy engine (Casbin, OPA) для сложных правил

Вывод

Аутентификация отвечает на вопрос "Кто ты?" и должна быть успешно пройдена перед доступом.

Авторизация отвечает на вопрос "Что ты можешь делать?" и должна проверяться перед каждым действием.

Оба механизма критичны и работают в последовательности — сначала аутентификация (проверка идентичности), затем авторизация (проверка прав).