Содержание:
- Сервер авторизации – что это?
- Чем аутентификация отличается от авторизации
- Какие задачи решает сервер авторизации
- Где используется централизованная авторизация
- Когда компании нужен отдельный сервер
- На что обратить внимание
- Частые ошибки при внедрении
- Ferrum как пример современного сервера авторизации
- Часто задаваемые вопросы
Практически любое современное приложение должно понимать, кто обращается к системе и какие действия этому пользователю разрешены. Пока сервис один, механизм входа обычно реализуют внутри самого приложения. Но по мере роста инфраструктуры появляются API, личные кабинеты, внутренние сервисы и микросервисы. Поддерживать отдельную систему авторизации в каждом из них становится сложно.
Именно поэтому компании переходят к централизованному серверу авторизации. Он берет на себя выдачу токенов доступа и управление правами, а также еще ряд функций.
Сервер авторизации – что это?
Это отдельный сервис, который отвечает за аутентификацию пользователей и управление доступом к приложениям. Вместо того, чтобы каждое приложение самостоятельно проверяло логин и пароль, эта задача выполняется централизованно.
Стандартный сценарий выглядит следующим образом:
- Пользователь открывает приложение и вводит учетные данные
- Приложение отправляет запрос серверу
- Сервер проверяет пользователя и его права
- После успешной проверки выдается токен доступа
- Остальные сервисы доверяют этому токену и предоставляют необходимые права без повторного входа
Благодаря такому подходу управление политиками безопасности сосредоточено в одном месте. Это упрощает сопровождение системы и снижает риск ошибок при разработке.
Чем аутентификация отличается от авторизации
Эти понятия часто используют как синонимы, хотя они решают разные задачи.
| Аутентификация | Авторизация |
| Подтверждает личность | Определяет права доступа |
| Отвечает на вопрос «Кто вы?» | Отвечает на вопрос «Что вам разрешено?» |
| Проверяет логин, пароль или другой способ входа | Проверяет роли, разрешения и политики доступа |
Сейчас новые решения часто объединяют обе функции. Они сначала подтверждают личность, а затем определяют, к каким данным и сервисам он может получить доступ.
Какие задачи решает сервер авторизации
С помощью центральной точки управления безопасностью всей системы можно:
- организовать единый вход (SSO) сразу в несколько приложений
- централизованно управлять ролями и правами
- выдавать и обновлять токены доступа по стандартам OAuth 2.0 и OpenID Connect
- контролировать срок действия пользовательских сессий
- обеспечить безопасную работу API и микросервисов
- применять единые политики безопасности
По мере развития проекта это упрощает сопровождение программного продукта.
Где используется централизованная авторизация
Например, в интернет-банке человек один раз проходит аутентификацию, а после получает доступ к мобильному приложению, личному кабинету и внутренним сервисам банка. Аналогичным образом работают крупные CRM, ERP и корпоративные порталы.
В микросервисной архитектуре это позволяет всем сервисам использовать единую систему проверки всех посетителей. Каждый микросервис получает уже проверенный токен доступа и не хранит собственную логику проверки паролей.
Такой подход уменьшает количество потенциальных уязвимостей и делает архитектуру более управляемой.
Когда компании нужен отдельный сервер
| Признак | Что это дает |
| Несколько приложений | Единая база посетителей и единый вход |
| Мобильное приложение и веб-версия | Общая система аутентификации |
| API для партнеров | Безопасная выдача токенов |
| Микросервисная архитектура | Отсутствие дублирования логики авторизации |
| Большое количество пользователей | Централизованное управление ролями и доступом |
| Развитие собственного программного продукта | Масштабируемость и упрощение сопровождения |
На что обратить внимание
| Критерий | Почему это важно |
| Поддержка OAuth 2.0 и OpenID Connect | Совместимость с современными приложениями |
| Производительность | Работа под высокой нагрузкой |
| Масштабируемость | Возможность роста без изменения архитектуры |
| Мониторинг | Контроль состояния сервиса и производительности |
| Open Source | Возможность аудита и доработки |
| Развертывание в собственной инфраструктуре | Контроль над данными и соответствие требованиям безопасности |
Частые ошибки при внедрении
Дублирование логики авторизации в разных сервисах
Распространенная ошибка – оставить проверку пользователей внутри каждого приложения после внедрения готового решения. В результате часть логики продолжает дублироваться, а изменения приходится вносить сразу в несколько сервисов.
Оптимальный подход – использовать сервер как единую точку аутентификации, а приложениям доверить только проверку полученных токенов и выполнение бизнес-логики.
Использование нестандартных механизмов вместо OAuth 2.0 и OpenID Connect
Иногда для внутренних проектов разрабатывают собственные схемы передачи токенов или проверки пользователей. На первых этапах это кажется удобным, однако в дальнейшем усложняет интеграцию новых сервисов и увеличивает стоимость сопровождения.
Использование общепринятых стандартов позволяет проще подключать новые API и сторонние сервисы.
Недостаточное внимание к мониторингу
После запуска важно контролировать состояние системы. Без мониторинга сложно своевременно обнаружить рост задержек, увеличение нагрузки или попытки несанкционированного доступа.
На практике рекомендуется отслеживать время обработки запросов, количество запросов в секунду (RPS), использование процессора и памяти, число активных соединений и количество ошибок.
Отсутствие защиты от атак на учетные записи
Сервер становится одной из критичных точек инфраструктуры, поэтому нужно предусмотреть защиту от подбора паролей и других распространенных атак.
К базовым мерам относятся ограничение количества неудачных попыток входа, временная блокировка по IP-адресу или устройству, запись событий в журнале безопасности и возможность быстрого реагирования администратора.
Выбор решения без учета будущего роста системы
Часто сервер выбирают исходя только из текущих требований. Однако по мере развития проекта могут появиться новые мобильные приложения, API или микросервисная архитектура.
Поэтому при выборе решения стоит заранее оценить возможности масштабирования, поддержку современных протоколов, наличие инструментов мониторинга и удобство интеграции с существующей инфраструктурой.
Ferrum как пример современного сервера авторизации
Ferrum Community Authorization Server – open-source сервер, включенный в реестр отечественного ПО.
Ferrum поддерживает OpenID Connect и может использоваться как самостоятельный сервис или как компонент программного продукта. Благодаря совместимости с отдельными API-сценариями Keycloak решение может рассматриваться при разработке новых систем или миграции существующих проектов.
В версии Ferrum v0.9.3 внимание было сосредоточено на трех направлениях: производительности, безопасности и наблюдаемости.
Для контроля состояния добавлены встроенные SRE-метрики с поддержкой Prometheus и готовой панелью Grafana. Это позволяет отслеживать длительность HTTP-запросов, загрузку процессора, использование памяти, количество активных горутин и текущую нагрузку.
Для защиты учетных записей реализован механизм противодействия brute-force атакам. После серии неудачных попыток входа Ferrum автоматически блокирует запросы по IP-адресу или идентификатору устройства, а администратор может вручную управлять блокировками.
Внимание было уделено и производительности. После перехода на маршрутизатор gin-gonic были проведены автоматические нагрузочные тесты, после которых Ferrum подтвердил стабильную работу при высокой нагрузке. По данным разработчиков, при 500 одновременно работающих пользователях значение p95 составило менее 10 мс, а при нагрузке до 5000 запросов в секунду и около 3000 одновременных пользователей – около 75 мс. При этом Ferrum потреблял менее 130 МБ оперативной памяти и использовал до двух ядер процессора.
При выборе решения важно учитывать поддерживаемые протоколы, производительность, возможности мониторинга, архитектуру проекта и требования к развертыванию. Для компаний, которым требуется мощный open-source вариант с поддержкой OpenID Connect и возможностью работы в своей инфраструктуре, одним из вариантов может стать Ferrum Community Authorization Server.
Хотите узнать, подойдет ли Ferrum для вашего проекта?
Поможем оценить совместимость с вашей архитектурой, ответим на технические вопросы и предложим оптимальный сценарий внедрения.