Открыть сервис
Главная → Блог → Сервер авторизации

Сервер авторизации

Сервер авторизации — это программно-аппаратный компонент распределённой вычислительной системы, который отвечает за проверку подлинности (аутентификацию) субъекта доступа (пользователя, устройства, другого сервиса) и выдачу ему разрешений (авторизацию) на доступ к защищённым ресурсам. В отличие от сервера ресурсов (прикладного сервера), который непосредственно предоставляет данные или функциональность, сервер авторизации выполняет функции централизованного управления доступом, выступая в роли доверенной стороны, удостоверяющей личность и определяющей права.

История и эволюция

Ранние этапы: локальная аутентификация

В первых многопользовательских операционных системах (например, UNIX, 1970-е годы) функции аутентификации и авторизации были встроены в ядро системы. Пользователь вводил имя и пароль, которые сравнивались с хешированными значениями в файле /etc/passwd (позже — /etc/shadow). Сервер авторизации как отдельный компонент не выделялся — все проверки выполнялись локально на каждой машине.

Появление сетевых сервисов: Kerberos

С развитием клиент-серверных архитектур и распределённых сетей (1980-е годы) возникла необходимость в единой точке аутентификации для множества сервисов. Протокол Kerberos, разработанный в Массачусетском технологическом институте (MIT) в рамках проекта Athena (1983–1988), стал первым широко распространённым решением, где сервер авторизации (Key Distribution Center, KDC) выступал центральным звеном. KDC выдавал билеты (tickets) — временные токены, подтверждающие личность пользователя и его права на доступ к конкретному серверу ресурсов. Kerberos до сих пор используется в Windows Active Directory и многих корпоративных системах.

Эра веб-приложений: OAuth и OpenID Connect

С распространением веб-приложений (конец 1990-х — 2000-е годы) возникла проблема «федеративной идентичности» — пользователь хотел использовать один аккаунт (например, Google или Facebook) для входа на множество сайтов. В 2007 году был опубликован протокол OAuth 1.0 (RFC 5849), а в 2012 году — OAuth 2.0 (RFC 6749), который стал де-факто стандартом для делегирования доступа. OAuth 2.0 определяет роли: клиент (приложение), сервер авторизации, сервер ресурсов и владелец ресурса (пользователь). Сервер авторизации выдаёт токены доступа (access tokens) и, опционально, токены обновления (refresh tokens).

Параллельно развивался протокол OpenID Connect (2014), построенный поверх OAuth 2.0, который добавил стандартизированную аутентификацию пользователя (получение ID-токена в формате JWT). OpenID Connect стал основой для современных систем единого входа (Single Sign-On, SSO).

Архитектура и принцип работы

Основные компоненты

Сервер авторизации в типичной реализации (например, Keycloak, Auth0, Azure AD) включает следующие модули:

  • Модуль аутентификации — проверяет учётные данные (пароль, биометрию, сертификат, одноразовый код) и устанавливает сессию пользователя.
  • Модуль авторизации — на основе политик доступа (например, на основе ролей — RBAC, или атрибутов — ABAC) принимает решение, разрешён ли запрашиваемый доступ.
  • Модуль выдачи токенов — генерирует и подписывает токены (обычно JWT — JSON Web Token), содержащие информацию о субъекте, его правах и времени жизни.
  • Модуль управления сессиями — поддерживает состояние сессии пользователя (например, через HTTP-куки или серверное хранилище).
  • Интерфейс для администратора — консоль управления пользователями, ролями, клиентами и политиками.

Типовой поток (на примере OAuth 2.0 Authorization Code Grant)

  1. Запрос авторизации: Пользователь через браузер обращается к клиентскому приложению (например, веб-сайту). Приложение перенаправляет пользователя на сервер авторизации с параметрами: client_id, redirect_uri, response_type=code, scope.
  2. Аутентификация: Сервер авторизации запрашивает у пользователя логин и пароль (или иные учётные данные). После успешной проверки сервер генерирует временный код авторизации (authorization code) и перенаправляет браузер обратно на redirect_uri клиента.
  3. Обмен кода на токен: Клиентское приложение отправляет на сервер авторизации POST-запрос с кодом авторизации, client_id и client_secret. Сервер проверяет код и выдаёт access_token (и, возможно, refresh_token).
  4. Доступ к ресурсу: Клиент использует access_token для запросов к серверу ресурсов (API). Сервер ресурсов проверяет токен (обычно по подписи) и, если он действителен, предоставляет запрошенные данные.

Классификация серверов авторизации

По типу развёртывания

  • Локальные (on-premises) — устанавливаются в инфраструктуре организации. Примеры: Keycloak (Red Hat), WSO2 Identity Server, Microsoft Active Directory Federation Services (AD FS).
  • Облачные (SaaS) — предоставляются как сервис. Примеры: Auth0 (Okta), Azure Active Directory (Microsoft), Google Cloud Identity, Amazon Cognito.
  • Гибридные — комбинируют локальное и облачное развёртывание, часто для синхронизации каталогов пользователей.

По поддерживаемым протоколам

  • OAuth 2.0 / OpenID Connect — современный стандарт для веба и мобильных приложений.
  • SAML 2.0 (Security Assertion Markup Language) — протокол на основе XML, популярный в корпоративных средах (например, для интеграции с Salesforce, Workday).
  • Kerberos — используется в Windows-доменах и UNIX-средах.
  • LDAP (Lightweight Directory Access Protocol) — протокол для доступа к каталогам пользователей; сервер авторизации может выступать как LDAP-сервер (например, OpenLDAP, 389 Directory Server).

По функциональности

  • Серверы аутентификации — только проверяют личность, не управляют правами доступа (например, RADIUS-сервер для VPN).
  • Серверы авторизации — принимают решения о доступе на основе политик (например, Policy Decision Point, PDP в архитектуре XACML).
  • Серверы единого входа (SSO) — позволяют пользователю аутентифицироваться один раз и получать доступ к нескольким приложениям без повторного ввода пароля.

Применение

Корпоративные системы

В крупных организациях сервер авторизации является центральным элементом управления доступом. Он интегрируется с каталогами пользователей (Active Directory, LDAP), позволяет реализовать политики паролей, многофакторную аутентификацию (MFA) и аудит доступа. Примеры: внедрение Keycloak для защиты внутренних веб-приложений, использование Azure AD для Office 365 и других облачных сервисов.

Веб-приложения и мобильные приложения

Сервер авторизации используется для реализации «Входа через Google» (Google Sign-In) или «Входа через ВКонтакте» (VK ID). В России популярны сервисы: VK ID (входит в экосистему VK), Яндекс ID, Сбер ID. Эти серверы авторизации реализуют протокол OAuth 2.0 и OpenID Connect, позволяя сторонним приложениям получать базовые данные пользователя (имя, email, аватар) без передачи пароля.

Микросервисная архитектура

В современных микросервисных системах (например, на базе Kubernetes) сервер авторизации выполняет роль централизованного шлюза безопасности. Каждый микросервис вместо самостоятельной проверки токена может делегировать эту задачу серверу авторизации или использовать библиотеки для проверки JWT (например, Spring Security, Express.js middleware). Популярные решения: OAuth2 Proxy, Pomerium, Ambassador.

Интернет вещей (IoT)

В IoT-системах сервер авторизации управляет доступом устройств к облачным платформам. Протокол OAuth 2.0 Device Authorization Grant (RFC 8628) позволяет устройствам с ограниченным интерфейсом (например, умные колонки, датчики) получать токены через вспомогательное устройство (смартфон).

Критика и ограничения

Сложность реализации

Протоколы OAuth 2.0 и OpenID Connect имеют множество вариантов (грантов) и конфигураций, что может приводить к ошибкам безопасности. Например, неправильная проверка redirect_uri или использование небезопасного implicit grant (который в OAuth 2.1 признан устаревшим) может привести к перехвату токенов.

Единая точка отказа

Централизованный сервер авторизации становится критическим компонентом. При его отказе пользователи теряют доступ ко всем защищённым ресурсам. Для снижения риска применяют кластеризацию (например, Keycloak с базой данных PostgreSQL и балансировщиком нагрузки) и репликацию.

Приватность данных

Сервер авторизации собирает данные о всех действиях пользователя (входы, выходы, запросы токенов). Это может создавать риски для конфиденциальности, особенно в условиях, когда сервер управляется третьей стороной (например, облачным провайдером). В России с 2015 года действует Федеральный закон № 152-ФЗ «О персональных данных», который требует локализации персональных данных на территории РФ, что влияет на выбор облачных серверов авторизации.

Зависимость от протоколов

Стандарты OAuth 2.0 и OpenID Connect не являются абсолютно безопасными — они требуют корректной реализации на стороне клиента и сервера. Известные уязвимости включают CSRF-атаки (Cross-Site Request Forgery), перехват кода авторизации через небезопасный канал (отсутствие HTTPS) и атаки на state-параметр.

Примеры популярных серверов авторизации

Открытые (open-source)

  • Keycloak (Red Hat) — один из самых популярных, поддерживает OAuth 2.0, OpenID Connect, SAML, LDAP, имеет встроенную поддержку MFA, социальных логинов и пользовательского интерфейса.
  • Apache Syncope — проект Apache Software Foundation, включает управление цифровыми идентичностями и сервер авторизации.
  • WSO2 Identity Server — полнофункциональный сервер с поддержкой SCIM, XACML, OAuth 2.0.
  • ORY Hydra — лёгкий сервер авторизации, ориентированный на микросервисы и контейнеризацию.

Коммерческие (проприетарные)

  • Auth0 (Okta) — облачный сервис, предоставляющий готовые SDK для многих языков программирования.
  • Azure Active Directory (Microsoft) — встроен в экосистему Azure, поддерживает гибридные сценарии с локальным AD.
  • Amazon Cognito — сервис AWS для аутентификации и авторизации мобильных и веб-приложений.
  • Okta — корпоративная платформа управления идентичностью, популярна в США и Европе.

Российские решения

  • VK ID (VK) — сервер авторизации экосистемы VK, используется для входа в VK, Почту Mail.ru, Облако Mail.ru и другие сервисы. Поддерживает OAuth 2.0 и OpenID Connect.
  • Яндекс ID (Яндекс) — централизованная система аутентификации для сервисов Яндекса и сторонних приложений.
  • Сбер ID (Сбер) — сервис единого входа для экосистемы Сбера, включая СберБанк, СберМаркет, СберЗдоровье.
  • ID.me (Россия) — решение для государственных и муниципальных услуг, используется на портале «Госуслуги» (ЕСИА — Единая система идентификации и аутентификации).

Законодательство и регулирование в России

В Российской Федерации серверы авторизации, используемые для обработки персональных данных, подпадают под действие Федерального закона № 152-ФЗ «О персональных данных». Согласно этому закону, операторы персональных данных (включая владельцев серверов авторизации) обязаны:

  • Обеспечивать локализацию баз данных персональных данных на территории РФ (статья 18.1).
  • Получать согласие субъекта на обработку данных (статья 9).
  • Уведомлять Роскомнадзор о начале обработки (статья 22).

Кроме того, с 1 декабря 2022 года вступил в силу Федеральный закон № 519-ФЗ, который обязывает владельцев сайтов и приложений, использующих иностранные серверы авторизации (например, Google Sign-In, Apple ID), предоставлять пользователям возможность авторизации через российские системы (ЕСИА, Госуслуги, VK ID, Яндекс ID, Сбер ID). Это требование направлено на обеспечение цифрового суверенитета и защиту персональных данных граждан РФ.

Источники

  1. RFC 6749 — «The OAuth 2.0 Authorization Framework» (IETF, 2012).
  2. RFC 7519 — «JSON Web Token (JWT)» (IETF, 2015).
  3. OpenID Connect Core 1.0 Specification (OpenID Foundation, 2014).
  4. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».
  5. Федеральный закон от 14.07.2022 № 519-ФЗ «О внесении изменений в Федеральный закон «Об информации, информационных технологиях и о защите информации».
  6. Документация Keycloak (Red Hat, 2023).
  7. «OAuth 2.0: The Definitive Guide» — Justin Richer, Antonio Sanso (O'Reilly, 2017).
  8. «Identity and Data Security for Web Development» — Jonathan LeBlanc, Tim Messerschmidt (O'Reilly, 2016).

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы