Аутентификация против авторизации: архитектурные паттерны для веб-приложений

Эти два понятия постоянно путают, и именно в этой путанице живут баги безопасности. То, что пользователь вошёл в систему (аутентифицирован), ничего не говорит о том, к каким записям, действиям или аккаунтам ему следует иметь доступ (авторизация).

Где происходит каждый из процессов

Распространённые паттерны аутентификации

• Пароль + безопасное хеширование — по-прежнему стандарт, требует корректного хеширования (bcrypt/argon2), ограничения частоты запросов и проверки на скомпрометированные пароли
• Magic links / одноразовые коды — убирают управление паролями, хорошо подходят для низкого трения в B2B и логинах в порталы
• OAuth / SSO — делегирует идентификацию доверенному провайдеру (Google, Microsoft, корпоративный IdP); снижает разрастание паролей в B2B-софте
• Многофакторная аутентификация (MFA) — дополнительный фактор помимо того, что вы знаете; стандарт для доступа администраторов и финансовых операций

Распространённые паттерны авторизации

• Ролевая модель доступа (RBAC) — права привязаны к ролям, роли привязаны к пользователям; хорошо масштабируется для внутренних инструментов и B2B-продуктов
• Атрибутная модель доступа (ABAC) — права вычисляются из атрибутов (отдел, регион, проект), а не фиксированных ролей; более гибко, но и сложнее
• Проверки на основе владения — пользователь может действовать с ресурсом, только если владеет им или принадлежит к его аккаунту; паттерн по умолчанию для клиентских порталов и мультитенантного SaaS

// Wrong: trusts an ID supplied by the client
async function getInvoice(invoiceId: string, accountId: string) {
  return db.invoice.findFirst({ where: { id: invoiceId, accountId } });
}

// Right: derives the account from the authenticated session
async function getInvoice(invoiceId: string, session: Session) {
  return db.invoice.findFirst({
    where: { id: invoiceId, accountId: session.accountId },
  });
}

Практический чек-лист

1. Разделите эти два понятия в коде

   Middleware аутентификации подтверждает личность и прикрепляет сессию. Проверки авторизации выполняются явно для каждого ресурса, а не предполагаются только на основе роли.

2. Ограничивайте каждый запрос аутентифицированной сессией

   Никогда не принимайте ID аккаунта, тенанта или владельца из клиентского ввода для решений о доступе.

3. Выбирайте RBAC первым, добавляйте ABAC только когда роли перестают подходить

   Большинство продуктов никогда не перерастают роли. Атрибутные правила добавляют реальную сложность; заслужите её, прежде чем добавлять.

4. Логируйте сбои авторизации

   Повторяющиеся сбои авторизации с одного аккаунта — сигнал, достойный оповещения, а не молчаливого игнорирования.

FAQ