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

Авторизация: определение, принципы и реализация

Авторизация — это процесс определения того, какие ресурсы и операции доступны аутентифицированному пользователю. Если аутентификация отвечает на вопрос "Кто ты?", то авторизация отвечает на вопрос "Что ты можешь делать?".

Ключевые различия: Аутентификация vs Авторизация

Основные модели авторизации

1. Role-Based Access Control (RBAC) Пользователю назначаются роли, каждой роли — набор прав.

Пользователь → Роль → Permissions → Ресурсы

Пример:
- Роль: Admin → Permissions: (read, write, delete) → Ресурсы: все
- Роль: Editor → Permissions: (read, write) → Ресурсы: публикуемые статьи
- Роль: Reader → Permissions: (read) → Ресурсы: опубликованные статьи

2. Attribute-Based Access Control (ABAC) Доступ определяется на основе атрибутов: пользователя, ресурса, окружения.

Пример правила ABAC:
Если user.department == "Finance" И resource.sensitivity == "high" 
  И request.time.hour >= 9 И request.time.hour <= 17
  И request.ip.location == "office"
То разрешить доступ

3. Access Control Lists (ACL) Для каждого ресурса определяется список пользователей/групп с их правами.

Ресурс: /documents/report-2024.pdf
ACL:
- alice@example.com: read, write
- bob@example.com: read
- engineering@company.com: read, write, share

Принципы безопасной авторизации

1. Принцип наименьших привилегий (Principle of Least Privilege) Пользователь должен иметь ровно столько прав, сколько ему нужно для работы, не больше.

❌ Плохо: Дать админу полные права ко всему
✅ Хорошо: Admin/support может читать данные, но не может удалять

2. Разделение ответственности (Separation of Duties) Критические операции требуют одобрения нескольких человек.

Пример: Удаление пользователя требует двух approval:
1. Manager одобряет
2. Security team одобряет

3. Временные права (Time-based Access) Права действуют только в определённый период времени.

Пример: Contractor имеет доступ только на период контракта (2026-01-01 до 2026-06-30)

Практическая реализация в системах

Вариант 1: Database-driven RBAC

TABLE users (id, email, role_id)
TABLE roles (id, name)
TABLE role_permissions (role_id, permission_id)
TABLE permissions (id, name)

-- Проверка прав:
SELECT p.* FROM permissions p
JOIN role_permissions rp ON rp.permission_id = p.id
JOIN roles r ON r.id = rp.role_id
JOIN users u ON u.role_id = r.id
WHERE u.id = ? AND p.name = 'delete_user'

Вариант 2: Policy-based (современный подход) Использование policy engine (Casbin, Open Policy Agent):

Policy:
user_id, resource, action, effect
alice, /documents/report.pdf, read, allow
alice, /documents/report.pdf, delete, deny
bob, /documents/*, read, allow
admin, /*, *, allow

Типичные ошибки

1. Авторизация только на фронте

❌ Плохо:
if (user.role === 'admin') {
  showDeleteButton()
}
// Пользователь может отправить DELETE запрос в обход UI

✅ Хорошо:
// Frontend: показывает кнопку
// Backend: проверяет прав перед удалением

2. Жёсткие права в коде

❌ Плохо:
if user.id == 123:  # hardcoded user_id
    allow_delete()

✅ Хорошо:
if has_permission(user, 'delete_resource'):
    allow_delete()

3. Забывчивость о третьем уровне (Row-level Security)

Users видят только свои данные, не чужие
Editors видят только статьи в своём категории

Инструменты и стандарты

• OAuth 2.0 / OpenID Connect: стандарты делегирования доступа
• JWT (JSON Web Tokens): передача прав в токене
• Casbin: популярный policy engine
• Apache Shiro / Spring Security: готовые фреймворки
• Keycloak: identity and access management server

Заключение

Авторизация — это критический слой безопасности. Её нужно реализовывать:

• На backend (обязательно)
• С учётом принципов наименьших привилегий
• С проверкой на каждом уровне (API, database, business logic)
• С аудитом действий для compliance