SSO: как работает единый вход и в чём его выгоды и риски

Single Sign-On, единый вход, позволяет пройти проверку личности один раз и после этого работать с несколькими приложениями без повторного ввода пароля. Знакомый пример: кнопка «войти через аккаунт большого сервиса» на стороннем сайте. Корпоративный вариант выглядит так же: сотрудник входит в рабочий портал и открывает почту, таск-трекер и хранилище без дополнительных логинов.

Идея решает две проблемы. Пользователю не нужно помнить десяток паролей, а организации удобно управлять доступом в одном месте: принять сотрудника, назначить права, при увольнении отключить учётную запись сразу везде.

Есть три роли. Пользователь. Провайдер идентификации, который проверяет личность: он хранит учётные записи, спрашивает пароль и второй фактор. Сервис, называемый также поставщиком услуг, который доверяет провайдеру и сам пароль не проверяет.

Когда вы открываете сервис, он перенаправляет вас к провайдеру. Провайдер проверяет вас или узнаёт по действующей сессии и возвращает сервису подтверждение: подписанное утверждение или токен с данными о вас. Сервис проверяет подпись, убеждается, что оно выпущено доверенным провайдером и предназначено ему, и открывает доступ.

В корпоративных системах давно распространён SAML, основанный на XML и подписанных утверждениях, часто используемый для веб-порталов. Более новый и популярный в потребительских сервисах OpenID Connect надстроен над OAuth 2.0 и передаёт информацию о пользователе в токене идентификации в формате JWT.

Их путают с OAuth, но различие важное: OAuth решает задачу делегирования доступа к ресурсам, а вопрос «кто это» закрывает именно надстройка OpenID Connect. Об этих различиях рассказано на страницах про OAuth и разницу между аутентификацией и авторизацией.

Выгоды заметны. Меньше паролей, проще централизованное включение двухфакторной защиты, единые политики, быстрый отзыв доступа, журнал входов в одном месте. Для пользователя это меньше поводов повторять пароли.

Обратная сторона: у провайдера появляется особая ценность. Скомпрометированная главная учётная запись открывает все связанные сервисы, поэтому её защищают сильнее всего, с обязательным вторым фактором, лучше аппаратным. Сбой или отключение учётной записи у провайдера лишает доступа ко всему сразу. А при входе через большой потребительский аккаунт сервис получает часть данных профиля, и провайдер узнаёт, какими сайтами вы пользуетесь.

В настройках основного аккаунта найдите раздел с подключёнными приложениями и сайтами: там перечислены сервисы, которым вы разрешили входить через него, и объём выданных прав. Уберите те, которыми не пользуетесь, и сократите разрешения там, где просят лишнее.

Включите сильную двухфакторную защиту на главной учётной записи и сохраните резервные способы восстановления. Выбирая между входом через аккаунт и отдельной регистрацией, взвесьте: вход через аккаунт удобнее, но привязывает сервис к аккаунту, а отдельная регистрация независима, если пароль уникален.

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

Важная возможность это автоматическое управление жизненным циклом: при приёме на работу учётные записи создаются в нужных сервисах, при увольнении отключаются. Ручное отключение в десятке приложений нередко забывают, и «забытые» доступы бывших сотрудников оказываются серьёзной причиной инцидентов. Единая точка отзыва прав закрывает эту проблему.

Небольшим командам полезно начать с малого: подключить к единому входу два-три самых важных сервиса, проверить сценарии восстановления доступа и лишь затем добавлять остальные. Так проще заметить проблемы до того, как ими зависнет вся работа. Заранее продумайте, что произойдёт при недоступности провайдера: сервисы должны иметь аварийный способ входа для администраторов.