Что такое Single Sign-On (SSO) и как работает единый вход
Средний сотрудник современной компании использует далеко не одну информационную систему. Корпоративная почта, CRM, ERP, облачное хранилище, Service Desk, мессенджеры, аналитические платформы и внутренние сервисы — каждому приложению необходимо понимать, кто именно пытается получить к нему доступ.
Если каждое приложение самостоятельно управляет учетными записями, пользователь вынужден постоянно проходить аутентификацию и работать с большим количеством паролей. Для ИТ- и ИБ-подразделений такая модель тоже неудобна: учетные записи необходимо создавать, блокировать и контролировать сразу в нескольких системах.
Решить эту проблему позволяет Single Sign-On (SSO) — технология единого входа. Пользователь проходит аутентификацию через доверенную систему идентификации, после чего получает доступ к связанным корпоративным приложениям без повторного ввода учетных данных.
Однако централизация аутентификации одновременно повышает требования к защите учетной записи и самого сервиса идентификации. Разберем, как устроен SSO, какие протоколы используются для единого входа и что необходимо учитывать при его внедрении.
Содержание:
Если каждое приложение самостоятельно управляет учетными записями, пользователь вынужден постоянно проходить аутентификацию и работать с большим количеством паролей. Для ИТ- и ИБ-подразделений такая модель тоже неудобна: учетные записи необходимо создавать, блокировать и контролировать сразу в нескольких системах.
Решить эту проблему позволяет Single Sign-On (SSO) — технология единого входа. Пользователь проходит аутентификацию через доверенную систему идентификации, после чего получает доступ к связанным корпоративным приложениям без повторного ввода учетных данных.
Однако централизация аутентификации одновременно повышает требования к защите учетной записи и самого сервиса идентификации. Разберем, как устроен SSO, какие протоколы используются для единого входа и что необходимо учитывать при его внедрении.
Содержание:
- SSO: что это такое и чем отличается от обычного входа
- Как работает единый вход SSO
- SAML, OpenID Connect и OAuth 2.0: в чем разница
- Что SSO дает корпоративной безопасности
- Какие риски появляются при использовании SSO
- Какие SSO-решения стоит рассматривать в 2026–2027 году
- Как внедрить SSO в компании
- Чем настоящий SSO отличается от менеджера или хранилища паролей
- Вопросы и ответы
- Заключение
Команда редакторов "Гладиаторы ИБ"
Дата публикации: 13.08.2026
Время прочтения
10 минут
Время прочтения
10 минут
SSO: что это такое и чем отличается от обычного входа
Single Sign-On (SSO) — технология, позволяющая пользователю пройти аутентификацию один раз и затем получать доступ к нескольким связанным приложениям без повторного ввода учетных данных. При этом приложения доверяют результату аутентификации, выполненной централизованным провайдером идентификации — Identity Provider (IdP).
При традиционной схеме каждое приложение может иметь собственную учетную запись:
Пользователь → CRM → логин и пароль
Пользователь → корпоративный портал → еще один логин и пароль
Пользователь → облачный сервис → еще одна аутентификация
При использовании SSO схема меняется:
Пользователь → Identity Provider → аутентификация → корпоративные приложения
Например, сотрудник утром проходит аутентификацию в корпоративной системе идентификации. Затем он открывает CRM, Service Desk и другие интегрированные приложения, а они получают подтверждение его личности от доверенного IdP.
Приложению в такой архитектуре необязательно самостоятельно хранить пароль пользователя. Централизованная система подтверждает его личность и передает приложению необходимую информацию.
Важно понимать: SSO не означает отсутствие аутентификации. Наоборот, аутентификация остается обязательной, но выполняется централизованно и ее результат может использоваться несколькими системами.
При традиционной схеме каждое приложение может иметь собственную учетную запись:
Пользователь → CRM → логин и пароль
Пользователь → корпоративный портал → еще один логин и пароль
Пользователь → облачный сервис → еще одна аутентификация
При использовании SSO схема меняется:
Пользователь → Identity Provider → аутентификация → корпоративные приложения
Например, сотрудник утром проходит аутентификацию в корпоративной системе идентификации. Затем он открывает CRM, Service Desk и другие интегрированные приложения, а они получают подтверждение его личности от доверенного IdP.
Приложению в такой архитектуре необязательно самостоятельно хранить пароль пользователя. Централизованная система подтверждает его личность и передает приложению необходимую информацию.
Важно понимать: SSO не означает отсутствие аутентификации. Наоборот, аутентификация остается обязательной, но выполняется централизованно и ее результат может использоваться несколькими системами.
Как работает единый вход SSO
В классической федеративной архитектуре участвуют три основных компонента:
- пользователь;
- Identity Provider (IdP) — система, которая выполняет аутентификацию;
- Service Provider (SP) или приложение — ресурс, к которому пользователь хочет получить доступ.
Конкретный процесс зависит от используемого протокола, но упрощенную схему можно представить следующим образом.
1. Пользователь обращается к приложению
Сотрудник открывает корпоративный сервис, например CRM.
Приложение определяет, что действующей пользовательской сессии нет и требуется подтверждение личности.
2. Приложение направляет пользователя к IdP
Вместо собственной формы входа приложение перенаправляет пользователя к доверенному провайдеру идентификации.
Им может выступать корпоративная IAM/IdP-платформа.
3. IdP аутентифицирует пользователя
Система идентификации проверяет личность сотрудника.
В зависимости от корпоративной политики могут использоваться:
- пароль;
- одноразовый код;
- аппаратный ключ безопасности;
- passkey;
- биометрическая аутентификация;
- несколько факторов одновременно.
Если пользователь недавно проходил аутентификацию и его сессия еще действительна, повторно вводить учетные данные может не потребоваться.
4. IdP формирует подтверждение
После успешной аутентификации Identity Provider передает приложению подтверждение личности пользователя.
Формат и способ передачи зависят от протокола — например, SAML или OpenID Connect.
5. Приложение предоставляет доступ
Приложение проверяет полученную информацию и создает собственную пользовательскую сессию.
Таким образом, пароль не требуется передавать каждому корпоративному приложению. Оно доверяет результату проверки, выполненной IdP.
SAML, OpenID Connect и OAuth 2.0: в чем разница
При обсуждении SSO постоянно встречаются три технологии: SAML, OpenID Connect и OAuth 2.0. Их нередко смешивают, хотя они решают разные задачи.
Технология | Основная задача | Где применяется |
SAML 2.0 | Федеративная аутентификация и передача утверждений об идентичности | Корпоративные веб-приложения, SaaS |
OpenID Connect | Аутентификация пользователя поверх OAuth 2.0 | Современные веб- и мобильные приложения |
OAuth 2.0 | Делегирование авторизации | Предоставление приложению ограниченного доступа к ресурсам/API |
SAML
Security Assertion Markup Language (SAML) — зрелый стандарт федеративной аутентификации, широко распространенный в корпоративных системах.
Identity Provider формирует SAML Assertion — подписанное утверждение, содержащее информацию об успешно аутентифицированном пользователе. Приложение проверяет его и на основании полученных данных предоставляет доступ.
SAML особенно распространен в традиционных enterprise-приложениях и SaaS.
OpenID Connect
OpenID Connect (OIDC) — протокол аутентификации, построенный поверх OAuth 2.0.
Он широко применяется в современных веб-приложениях, мобильных клиентах и облачных сервисах. Для передачи информации используются JSON-структуры и токены, что хорошо соответствует современной архитектуре приложений. Microsoft, например, рекомендует рассматривать OIDC для современных приложений, тогда как SAML сохраняет широкую совместимость с корпоративными системами.
OAuth 2.0
Здесь возникает наиболее частая терминологическая ошибка.
OAuth 2.0 сам по себе не является протоколом аутентификации. Его основная задача — делегированная авторизация.
Проще говоря:
аутентификация отвечает на вопрос «Кто вы?»;
авторизация — «Что вам разрешено делать?».
Например, приложение может получить ограниченное разрешение обращаться к определенному API от имени пользователя. Для этого пользователю необязательно передавать стороннему приложению свой пароль.
OpenID Connect добавляет к OAuth 2.0 механизм идентификации пользователя, благодаря чему его можно использовать для аутентификации и построения SSO.
Что SSO дает корпоративной безопасности
SSO часто внедряется ради удобства сотрудников, но правильно построенная система единого входа дает значительно более важный эффект — централизацию управления идентификацией и доступом.
Меньше паролей
Чем больше учетных записей приходится использовать сотруднику, тем выше вероятность небезопасного поведения: повторного использования паролей, создания простых комбинаций или хранения учетных данных в неподходящих местах.
SSO сокращает количество отдельных паролей и точек, в которых они используются.
Централизованное применение MFA
Одно из ключевых преимуществ — возможность внедрить многофакторную аутентификацию (MFA) централизованно.
Вместо настройки MFA отдельно в десятках приложений организация может применять требования на уровне Identity Provider.
Единые политики доступа
Современные платформы идентификации позволяют принимать решение о доступе с учетом дополнительного контекста:
- пользователя;
- группы;
- приложения;
- состояния устройства;
- местоположения;
- характеристик подключения;
- уровня риска;
- используемого метода аутентификации.
Таким образом, SSO может стать одним из компонентов архитектуры Zero Trust.
Ускорение блокировки сотрудников
При увольнении сотрудника критически важно своевременно прекратить его доступ к корпоративным системам.
При децентрализованной модели администраторам приходится контролировать множество отдельных учетных записей. При централизованной идентификации значительная часть доступа может управляться через единую систему.
Улучшение мониторинга
Централизация аутентификации создает удобную точку для регистрации событий:
- успешных входов;
- неудачных попыток;
- срабатывания MFA;
- подозрительных аутентификаций;
- попыток доступа к приложениям.
Эти события можно передавать в SIEM и использовать при обнаружении и расследовании инцидентов.
Какие риски появляются при использовании SSO
Централизация одновременно является главным преимуществом и одним из основных рисков Single Sign-On.
Если множество систем доверяет одному Identity Provider, компрометация центральной учетной записи может открыть злоумышленнику доступ сразу к нескольким ресурсам. На этот риск обращают внимание и поставщики SSO-решений.
Компрометация основной учетной записи
Если злоумышленник получает возможность успешно пройти центральную аутентификацию, последствия потенциально серьезнее, чем при компрометации отдельного пароля от одного приложения.
Поэтому SSO практически нельзя рассматривать отдельно от MFA и других механизмов усиленной аутентификации.
Кража сессионных данных
Даже сложный пароль и MFA не решают абсолютно все проблемы.
Целью атаки может стать уже созданная пользовательская сессия или токен. Поэтому необходимо контролировать срок жизни сессий, повторную аутентификацию для критичных операций и аномальное использование учетных записей.
Ошибки конфигурации
Неправильные redirect URI, некорректная проверка подписей, слишком широкие разрешения, ошибки обработки токенов и другие проблемы способны снизить защищенность SSO.
Особое внимание требуется собственным и устаревшим приложениям, для которых интеграция выполняется вручную.
Отказ IdP
Центральная система идентификации становится критически важным компонентом инфраструктуры.
Проблемы с ее доступностью могут одновременно затронуть множество бизнес-приложений. Поэтому при проектировании необходимо учитывать отказоустойчивость и аварийные сценарии доступа.
Избыточные права
SSO отвечает прежде всего за удобную и централизованную аутентификацию, но не отменяет необходимость корректного управления авторизацией.
Пользователь может успешно подтвердить личность, но это не означает, что ему следует предоставить доступ ко всем функциям приложения.
Какие SSO-решения стоит рассматривать в 2026–2027 году
К 2026 году SSO фактически стал частью более широкого рынка Identity and Access Management (IAM). Поэтому при выборе платформы имеет смысл оценивать не только функцию «одного входа», но и управление жизненным циклом учетных записей, MFA, Conditional Access, поддержку passkeys, интеграцию с локальными каталогами и облачной инфраструктурой.
Среди решений, которые целесообразно включать в первоначальный список для корпоративного проекта:
Microsoft Entra ID
Логичный кандидат для организаций, уже активно использующих Microsoft 365 и экосистему Microsoft.
Entra ID поддерживает федеративный SSO через SAML и OpenID Connect, а также варианты интеграции для приложений, которые пока не поддерживают современные протоколы. Microsoft также развивает Conditional Access и централизованное управление корпоративными приложениями.
Okta
Одна из наиболее известных независимых облачных Identity-платформ. Обычно рассматривается в организациях с большим количеством SaaS-сервисов и разнородной инфраструктурой.
Ping Identity
Платформа управления идентификацией и доступом, которую стоит рассматривать для крупных корпоративных и гибридных инфраструктур, где важны федерация и интеграция различных систем идентификации.
Cisco Duo
Duo сочетает SSO с многофакторной аутентификацией и политиками доступа. Актуальная версия Duo SSO может работать как SAML 2.0 Identity Provider и OpenID Connect Provider, поддерживает passkeys, security keys и дополнительные проверки пользователя и устройства.
При этом выбирать SSO-платформу только по известности бренда неправильно. Значение имеют существующий каталог пользователей, используемые приложения, облачная стратегия, требования к MFA, наличие legacy-систем, возможности автоматизации provisioning/deprovisioning и требования к отказоустойчивости.
Как внедрить SSO в компании
Внедрение единого входа лучше рассматривать как проект по управлению идентификацией, а не просто как подключение нескольких приложений к IdP.
1. Провести инвентаризацию приложений
Необходимо определить:
- какие корпоративные приложения используются;
- где находятся учетные записи;
- какие способы аутентификации поддерживаются;
- есть ли SAML или OIDC;
- используются ли локальные приложения;
- какие системы являются критичными.
На этом этапе становится понятно, какую долю инфраструктуры вообще можно перевести на современный федеративный SSO.
2. Определить источник идентификационных данных
Нужно определить, где будет находиться «источник истины» о сотрудниках и учетных записях.
Это может быть локальный каталог, облачная Identity-платформа или гибридная архитектура.
3. Выбрать протоколы интеграции
Для современных приложений обычно предпочтителен OIDC, если он корректно поддерживается продуктом. В корпоративной инфраструктуре при этом остается огромное количество приложений, использующих SAML.
Для legacy-систем могут потребоваться другие способы интеграции.
4. Спроектировать MFA и политики доступа
Включить SSO без усиленной защиты центральной идентификации — плохая идея.
Необходимо определить:
- кому требуется MFA;
- какие факторы допустимы;
- какие приложения требуют усиленной проверки;
- когда нужна повторная аутентификация;
- какие устройства считаются доверенными;
- какие события должны приводить к ограничению доступа.
5. Настроить пилотную группу
Переводить всю организацию на новую модель одновременно необязательно.
Разумнее выбрать несколько приложений и ограниченную группу пользователей, протестировать вход, выход, MFA, блокировку учетных записей и аварийные сценарии.
Microsoft также рекомендует тестировать конфигурацию SSO в непроизводственной среде перед широким внедрением.
6. Автоматизировать жизненный цикл учетных записей
SSO значительно эффективнее, когда он связан с процессами Identity Governance.
Новый сотрудник должен автоматически получать необходимые права, при переводе — менять их, а при увольнении — своевременно терять доступ.
7. Подключить мониторинг
События аутентификации необходимо собирать и анализировать.
Особенно интересны:
- многочисленные неудачные входы;
- необычные географические точки;
- новые устройства;
- нетипичное время активности;
- обход MFA;
- изменения политик;
- действия привилегированных пользователей.
Чем настоящий SSO отличается от менеджера или хранилища паролей
Внешне эти технологии действительно могут выглядеть похоже: пользователю не приходится каждый раз вручную вводить логин и пароль.
Но технически механизмы принципиально отличаются.
При настоящем федеративном SSO приложение доверяет Identity Provider и принимает от него подтверждение личности.
Менеджер паролей работает иначе: он хранит отдельные учетные данные и помогает пользователю подставить их в форму входа.
Существуют и промежуточные варианты. Например, Microsoft Entra ID поддерживает password-based SSO для legacy-приложений: система хранит учетные данные и автоматически передает их приложению. Это позволяет обеспечить похожий пользовательский опыт, хотя технически такая схема отличается от федеративного SSO через SAML или OIDC.
Поэтому наличие кнопки «войти один раз» еще не говорит о том, какая именно технология находится под ней.
Но технически механизмы принципиально отличаются.
Критерий | SSO | Менеджер паролей |
Количество отдельных учетных данных | Может быть централизовано | Обычно сохраняются отдельные пароли |
Кто подтверждает личность | Identity Provider | Каждое приложение самостоятельно |
Передача пароля приложению | При федеративном SSO не требуется | Пароль подставляется в форму |
Централизованная MFA | Да | Зависит от приложения |
Федерация идентификации | Да | Нет |
Централизованная политика доступа | Да | Ограниченно |
SAML/OIDC | Используются | Обычно нет |
Управление корпоративными идентичностями | Основная задача | Не основная задача |
При настоящем федеративном SSO приложение доверяет Identity Provider и принимает от него подтверждение личности.
Менеджер паролей работает иначе: он хранит отдельные учетные данные и помогает пользователю подставить их в форму входа.
Существуют и промежуточные варианты. Например, Microsoft Entra ID поддерживает password-based SSO для legacy-приложений: система хранит учетные данные и автоматически передает их приложению. Это позволяет обеспечить похожий пользовательский опыт, хотя технически такая схема отличается от федеративного SSO через SAML или OIDC.
Поэтому наличие кнопки «войти один раз» еще не говорит о том, какая именно технология находится под ней.
Вопросы и ответы
Что такое SSO простыми словами?
Single Sign-On — технология, при которой пользователь один раз подтверждает свою личность через доверенную систему идентификации, а затем получает доступ к связанным корпоративным приложениям без повторного ввода учетных данных.
Безопаснее ли SSO обычных паролей?
При правильной реализации SSO может повысить безопасность за счет централизации аутентификации, MFA и политик доступа. Но одновременно центральная учетная запись становится более ценной целью для злоумышленника. Поэтому защищать IdP необходимо особенно тщательно.
Нужна ли MFA, если компания использует SSO?
Да, сочетание SSO и MFA является значительно более безопасным подходом, чем использование только единого пароля. Компрометация основной учетной записи при SSO потенциально предоставляет доступ сразу к нескольким связанным ресурсам.
SSO и OAuth — одно и то же?
Нет. SSO — модель единого входа, а OAuth 2.0 предназначен прежде всего для делегирования авторизации. Для аутентификации поверх OAuth 2.0 используется OpenID Connect.
Что лучше использовать — SAML или OpenID Connect?
Это зависит от приложения. SAML остается широко распространенным стандартом для корпоративных веб-приложений. OpenID Connect хорошо подходит для современных веб- и мобильных приложений. При выборе необходимо в первую очередь учитывать то, какие стандарты официально и корректно поддерживает интегрируемая система.
Можно ли подключить к SSO старые приложения?
Да, но способ зависит от приложения. Помимо SAML и OIDC, корпоративные Identity-платформы могут поддерживать Integrated Windows Authentication, header-based и password-based SSO. Для части legacy-систем может потребоваться дополнительный proxy или модернизация самого приложения.
Что произойдет, если SSO-сервис станет недоступен?
Это зависит от архитектуры и уже существующих пользовательских сессий, однако отказ центрального IdP способен нарушить вход сразу в несколько корпоративных систем. Поэтому для критичной инфраструктуры необходимо заранее проектировать отказоустойчивость и аварийный доступ.
Заключение
Single Sign-On решает гораздо более серьезную задачу, чем избавление сотрудников от необходимости постоянно вводить пароли. SSO позволяет перенести аутентификацию из множества разрозненных приложений в контролируемую Identity-инфраструктуру и централизованно применять MFA, политики доступа и мониторинг.
Но вместе с этим меняется модель риска. Identity Provider становится одной из ключевых систем безопасности организации: его компрометация или неправильная настройка потенциально влияет сразу на множество корпоративных ресурсов.
Поэтому внедрение SSO необходимо начинать с инвентаризации приложений и идентификационной инфраструктуры, выбора подходящих протоколов и проектирования модели доступа. А уже затем — подключать приложения, автоматизировать жизненный цикл учетных записей и постепенно распространять единый вход на всю организацию.
Если необходимо внедрить Single Sign-On, подобрать IAM/IdP-платформу или разобраться с SAML, OpenID Connect, MFA и интеграцией существующих корпоративных приложений, специалисты «Гладиаторов информационной безопасности» помогут спроектировать архитектуру, сравнить решения и реализовать систему единого доступа с учетом требований вашей инфраструктуры и информационной безопасности.
Но вместе с этим меняется модель риска. Identity Provider становится одной из ключевых систем безопасности организации: его компрометация или неправильная настройка потенциально влияет сразу на множество корпоративных ресурсов.
Поэтому внедрение SSO необходимо начинать с инвентаризации приложений и идентификационной инфраструктуры, выбора подходящих протоколов и проектирования модели доступа. А уже затем — подключать приложения, автоматизировать жизненный цикл учетных записей и постепенно распространять единый вход на всю организацию.
Если необходимо внедрить Single Sign-On, подобрать IAM/IdP-платформу или разобраться с SAML, OpenID Connect, MFA и интеграцией существующих корпоративных приложений, специалисты «Гладиаторов информационной безопасности» помогут спроектировать архитектуру, сравнить решения и реализовать систему единого доступа с учетом требований вашей инфраструктуры и информационной безопасности.