Конспект

YouTubeОбновленный курс "Системный аналитик". Урок 17: Авторизация.

Авторизация: от основ до технической реализации

Ключевые тезисы

  • Авторизация — это многоступенчатый процесс, включающий идентификацию, аутентификацию и собственно авторизацию.
  • Технически доступ к ресурсам делится на публичные и приватные запросы.
  • Для приватных запросов используются схемы авторизации: Basic, Bearer (JWT) и протокол OAuth 2.0.
  • Современные распределённые системы часто используют внешние сервисы (Identity Provider, Authorization Server) или готовые решения (Keycloak, сервисы Google, Яндекс).

Основное содержание

Три этапа процесса доступа

Процесс, который в быту называют "авторизацией", состоит из трёх последовательных этапов:

Идентификация

  • Процедура, позволяющая системе понять, "кто стучится".
  • Пользователь предоставляет идентификатор (логин, email, телефон, ИНН компании).
  • Система проверяет, есть ли такой идентификатор в базе. На этом этапе не проверяются права или подлинность.

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

  • Процедура проверки подлинности.
  • Пользователь доказывает, что он — это тот, за кого себя выдал на этапе идентификации.
  • Использует доказательные механизмы: знание (пароль, пин-код), владение (телефон для SMS, токен, электронная подпись), биометрию (отпечаток, лицо).
  • Многофакторная аутентификация — комбинация нескольких механизмов (например, пароль + SMS-код).

Авторизация

  • Процедура наделения аутентифицированного пользователя определёнными правами и ролями в системе.
  • Определяет, что пользователь может делать (просматривать, редактировать, удалять).
  • Примеры ролей: гость, пользователь, администратор.
  • Если пользователь не авторизован, ему обычно присваивается роль "гость" с минимальными правами.

Типы запросов

  • Публичные (Public) запросы: доступны всем, ограничений нет (например, просмотр каталога без входа).
  • Приватные (Private) запросы: требуют прохождения процесса авторизации для получения доступа к защищённым ресурсам.

Технические схемы авторизации

Basic-авторизация

  • Простейшая схема. Логин и пароль кодируются (например, в Base64) и передаются в заголовке (Authorization) каждого запроса.
  • Сервер декодирует данные, проводит аутентификацию и авторизацию.
  • Недостаток: учётные данные передаются с каждым запросом. Подходит для простых систем или внутренней интеграции.

Bearer-авторизация (JWT)

  • Использует JWT-токен (JSON Web Token) — компактную строку для безопасной передачи данных.
  • Алгоритм:
    1. Клиент обращается к сервису авторизации с логином и паролем.
    2. Получает JWT-токен.
    3. Передаёт этот токен в заголовке (Authorization: Bearer <token>) при запросах к другим сервисам.
  • Структура JWT (три части, разделённые точками):
    1. Header: тип токена и алгоритм подписи.
    2. Payload (полезная нагрузка): содержит клеймы (claims) — данные о пользователе, его роли и права.
    3. Signature (подпись): нужна для проверки подлинности токена.
  • Преимущество: не нужно передавать логин/пароль каждый раз. Токен имеет время жизни.

Протокол OAuth 2.0 и OpenID Connect

Стандарты для безопасного делегирования доступа в распределённых системах.

OAuth 2.0

  • Протокол авторизации без аутентификации.
  • Позволяет получить доступ к ресурсам, не передавая пароль.
  • Выдаёт access token (часто JWT) для доступа к API.
  • Может выдавать refresh token для обновления access token'а без повторного ввода логина и пароля.
  • Пример: "Войти через Google/VK" — сторонний сервис получает доступ только к разрешённым данным (email), но не к паролю от аккаунта.

OpenID Connect (OIDC)

  • Надстройка над OAuth 2.0 для аутентификации.
  • Позволяет клиенту убедиться в личности пользователя и получить базовую информацию о нём.
  • Добавляет к процессу OAuth ID-токен с данными пользователя.

Компоненты архитектуры OAuth/OIDC

  • Identity Provider (IDP): отвечает за идентификацию, аутентификацию и хранение учётных записей. Возвращает информацию о пользователе.
  • Authorization Server (AS): отвечает за выдачу токенов (access, refresh, ID) и проверку разрешений клиентов.

Готовые решения и выбор технологии

  • Провайдеры: Google Accounts, Microsoft Active Directory, Яндекс.
  • Open-source: Keycloak — популярное решение, объединяющее IDP и AS, с возможностями управления пользователями.
  • Выбор схемы зависит от архитектуры:
    • Монолит/Single Page Application: может быть достаточно Basic-авторизации.
    • Микросервисная/распределённая архитектура: необходим отдельный сервис аутентификации (OAuth 2.0, OIDC) или готовое решение (Keycloak).
    • Решение принимается архитектором и заказчиком с учётом политик безопасности, существующей инфраструктуры и требований.

Дополнительные аспекты безопасности

Капча (CAPTCHA)

  • Используется на этапе аутентификации (чаще при регистрации или входе).
  • Цель — отличить человека от робота и защититься от автоматических атак.
  • Необходима для публичных сервисов; для внутренних порталов может не требоваться.

Многофакторная аутентификация (MFA)

  • Частота использования зависит от стандартов безопасности компании и уровня обрабатываемых данных.
  • Обязательна для сервисов, работающих с чувствительной информацией (банки, медицинские данные, госуслуги), и регулируется стандартами вроде PCI DSS.

Хранение токенов на клиенте

  • JWT-токены для веб-приложений часто хранятся в куках (cookies) или локальном хранилище (localStorage).
  • Хранение в куках обычно безопаснее (защита от некоторых видов XSS-атак). Удаление куки приводит к разрыву сессии.

Выводы

  1. Авторизация — это комплексный процесс, начинающийся с идентификации пользователя и заканчивающийся выдачей ему конкретных прав.
  2. JWT-токены и протокол OAuth 2.0 стали стандартом для авторизации в современных распределённых и микросервисных архитектурах.
  3. Выбор конкретной схемы и инструментов (Basic, Keycloak, облачный провайдер) является архитектурным решением и зависит от масштаба, требований безопасности и существующей инфраструктуры проекта.