Web Browser SSO Profile

Web Browser SSO Profile — это спецификация или набор протоколов, определяющих механизм единого входа (Single Sign-On, SSO) для веб-браузеров, позволяющий пользователю аутентифицироваться один раз и получать доступ к нескольким независимым веб-приложениям без повторного ввода учётных данных. Данный профиль описывает, как стандартные протоколы аутентификации, такие как SAML (Security Assertion Markup Language) или OpenID Connect, адаптируются для работы через браузер, используя перенаправления HTTP и куки.

История и предпосылки появления

До появления SSO-профилей для браузеров пользователи вынуждены были вводить логин и пароль для каждого отдельного веб-сервиса. Это создавало неудобства и снижало безопасность, так как пользователи часто использовали одинаковые пароли. В середине 2000-х годов, с ростом числа корпоративных веб-приложений и облачных сервисов, возникла потребность в централизованной аутентификации.

Первым широко распространённым протоколом, реализующим SSO для браузеров, стал SAML 2.0, принятый в 2005 году. Его Web Browser SSO Profile был формализован в спецификации OASIS (Organization for the Advancement of Structured Information Standards). Позднее, с развитием REST-архитектур и мобильных приложений, появился OpenID Connect (2014 год), который также включает свой профиль для браузеров, основанный на OAuth 2.0. В России, как и в мире, эти протоколы активно используются в государственных информационных системах (например, ЕСИА — Единая система идентификации и аутентификации) и корпоративных порталах.

Основные принципы работы

Web Browser SSO Profile предполагает участие трёх сторон:

1. Пользователь (User Agent) — веб-браузер.
2. Поставщик услуг (Service Provider, SP) — веб-приложение, к которому пользователь хочет получить доступ.
3. Поставщик идентификации (Identity Provider, IdP) — сервер, хранящий учётные данные пользователя и выдающий токены или утверждения об аутентификации.

Процесс обычно включает следующие шаги:

1. Пользователь пытается открыть защищённую страницу на SP.
2. SP не находит локальной сессии (куки) и перенаправляет браузер на IdP с запросом аутентификации.
3. IdP проверяет, есть ли у пользователя активная сессия (например, куки IdP). Если нет, IdP запрашивает логин и пароль (или другой фактор аутентификации).
4. После успешной аутентификации IdP формирует токен (например, SAML-утверждение или ID-токен) и перенаправляет браузер обратно на SP.
5. SP проверяет токен (подпись, срок действия, аудиторию) и создаёт локальную сессию для пользователя.

Ключевые особенности для браузера

• Перенаправления HTTP: все взаимодействия между SP и IdP происходят через браузер, что исключает необходимость прямой связи между серверами.
• Куки: используются для поддержания сессии как на стороне IdP, так и на стороне SP.
• Безопасность: токены передаются через браузер, поэтому они должны быть подписаны и, в идеале, зашифрованы. Для предотвращения атак (например, CSRF — Cross-Site Request Forgery) используются механизмы вроде state или RelayState.

Виды и протоколы

SAML 2.0 Web Browser SSO Profile

Это наиболее зрелый и широко распространённый профиль. Он основан на XML-токенах и поддерживает два основных сценария:

• SP-Initiated SSO: пользователь сначала обращается к SP, который инициирует аутентификацию.
• IdP-Initiated SSO: пользователь сначала входит в IdP, а затем выбирает SP из списка.

В России SAML 2.0 используется в системах электронного правительства (например, портал «Госуслуги») и в корпоративных средах (например, Active Directory Federation Services от Microsoft).

OpenID Connect (OIDC) Browser Flow

Этот протокол, построенный на OAuth 2.0, использует JSON-токены (JWT) и более прост в реализации для современных веб-приложений. Основной поток для браузера — Authorization Code Flow with PKCE (Proof Key for Code Exchange), который обеспечивает защиту от перехвата кода авторизации. OIDC также поддерживает Implicit Flow (устаревший, не рекомендуется для новых систем).

Kerberos и NTLM (для внутренних сетей)

В корпоративных средах, особенно в Windows-доменах, используется Integrated Windows Authentication (IWA), где браузер автоматически передаёт учётные данные (например, через Kerberos). Этот профиль не требует перенаправлений, но работает только в пределах доверенной сети.

Применение

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

Web Browser SSO Profile широко применяется в компаниях для унификации доступа к внутренним ресурсам: CRM, ERP, почтовые системы, файловые хранилища. Например, сотрудник входит в корпоративный портал (IdP), и все остальные приложения (SP) автоматически узнают его.

Государственные и муниципальные услуги

В России ЕСИА (Единая система идентификации и аутентификации) использует SAML 2.0 для обеспечения доступа к порталу «Госуслуги» и другим ведомственным системам. Гражданин входит один раз, и его данные передаются в налоговую, Пенсионный фонд, МВД и другие органы.

Облачные сервисы

Провайдеры облачных услуг (например, Google Workspace, Microsoft 365, Salesforce) поддерживают SSO через SAML или OIDC. Это позволяет организациям использовать собственный IdP (например, Active Directory) для управления доступом к облачным приложениям.

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

Уязвимости

• Фишинг: пользователь может быть перенаправлен на поддельный IdP, если не проверять URL.
• Перехват токенов: если соединение не защищено TLS, токены могут быть украдены.
• Атаки на перенаправления: злоумышленник может изменить RelayState или redirect_uri, чтобы перенаправить пользователя на вредоносный сайт.

Зависимость от единой точки отказа

Если IdP выходит из строя, пользователи теряют доступ ко всем подключённым SP. Это требует высокой доступности и резервирования IdP.

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

Настройка SSO-профиля требует понимания криптографии, управления сертификатами и конфигурации как SP, так и IdP. Ошибки в настройке могут привести к утечкам данных.

Проблемы с конфиденциальностью

IdP может отслеживать, к каким SP обращается пользователь, что создаёт риски для приватности. В некоторых системах (например, в рамках закона о персональных данных в РФ) это требует дополнительных мер защиты.

Интересные факты

• Первый протокол SSO для браузеров был предложен компанией Microsoft в 1999 году (Passport), но он не получил широкого распространения из-за проблем с безопасностью и конфиденциальностью.
• В России, согласно Федеральному закону № 152-ФЗ «О персональных данных», все системы SSO, обрабатывающие данные граждан, должны использовать сертифицированные средства криптографической защиты информации (СКЗИ).
• Протокол SAML 2.0 до сих пор остаётся стандартом в государственных системах многих стран, включая США (федеральные программы) и страны Евросоюза (eIDAS).

Источники

1. OASIS Standard, «Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0», 2005.
2. OpenID Foundation, «OpenID Connect Core 1.0», 2014.
3. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».
4. Техническая документация ЕСИА (Единая система идентификации и аутентификации), Минцифры России.
5. RFC 6749 — «The OAuth 2.0 Authorization Framework», 2012.
6. RFC 7519 — «JSON Web Token (JWT)», 2015.