SSO: что это такое и зачем компании единый вход

Единый вход простыми словами

Single Sign-On — схема, при которой человек входит один раз и дальше без новых паролей попадает во все подключённые системы. Логин и пароль проверяет только одна система, сервер авторизации, а остальные ей доверяют.

Самый понятный пример из жизни — аккаунт Яндекса или Google. Вошёл в почту, и диск, календарь и документы уже открыты. В компании всё так же, только вместо почты и диска — CRM, GitLab, база знаний, трекер задач и внутренние дашборды.

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

Что такое SSO с точки зрения архитектуры

В схеме три участника. Пользователь хочет открыть сервис. Сервис, его называют клиентом или Service Provider, сам пароли не проверяет. Сервер авторизации, Identity Provider, хранит учётные записи и решает, пускать человека или нет.

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

Протоколы SSO авторизации

Единый вход держится на стандартных протоколах, поэтому его можно подключить почти к любой системе. Основных три, и их часто путают между собой.

Для новых веб-сервисов я выбираю OpenID Connect: библиотеки для него есть почти в каждом языке, а подключение занимает меньше часа.

OAuth и OpenID Connect: в чём разница

OAuth 2.0 отвечает на вопрос «что приложению можно делать от моего имени», а не «кто я». Поэтому для входа поверх него сделали OpenID Connect, который добавляет ID-токен с данными пользователя. OAuth 2.0 описан в стандарте IETF RFC 6749 в 2012 году, спецификацию OpenID Connect Core 1.0 OpenID Foundation выпустила в 2014-м.

SAML старше: версию 1.0 консорциум OASIS утвердил в ноябре 2002 года, актуальную SAML 2.0 — в марте 2005-го. Он до сих пор живёт в корпоративных продуктах. Если внешний сервис умеет только его, сервер авторизации всё равно справится: большинство решений поддерживают оба протокола.

Почему мы пришли к единому входу

У нас в Alto вайбкодит вся компания, даже пиар. Сначала я думал собрать всё в один большой сервис с модулями. Но при таком подходе одна неудачная правка в общем коде ломает работу всем остальным, и это меня остановило.

Второй вариант — главный сервис, к которому остальные подключаются по REST API. Мы попробовали, и в повседневной работе это оказалось неудобно: каждому новому сервису нужна своя интеграция с главным.

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

Как выдаются и отзываются доступы

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

Иногда галочек две. В сервисе конспектов встреч обычный пользователь видит только свои встречи, а администратор — все. Когда человек увольняется, весь его доступ забирается в один клик, и ни в одном сервисе не остаётся забытой учётной записи.

Как подключить сервис к единому входу

Сервис, который навайбкодил сотрудник, мы подключаем, как только им начинает пользоваться больше одного человека. Сейчас это занимает 30–60 минут.

С внешними продуктами ещё проще. GitLab, Confluence и Planfix мы тоже подключили, ведь почти у всех крупных вендоров настройки для единого входа уже есть.

• Зарегистрировать сервис на сервере авторизации и указать его адрес.
• Прописать разрешённые адреса возврата после входа, без звёздочек.
• Подключить готовую библиотеку OpenID Connect для своего стека.
• Закрыть все страницы сервиса: без токена — на страницу входа.
• Связать роли из токена с правами внутри сервиса.
• Убрать старую форму входа, чтобы в обход не осталось дверей.

Единый вход SSO и защита учётных записей

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

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

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

Плюсы и риски единого входа

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

Главный риск — единая точка отказа. Если сервер авторизации недоступен, не войти никуда, поэтому его держат минимум в двух экземплярах и регулярно бэкапят базу с пользователями и ролями.

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

Когда SSO авторизация не нужна

Если в компании пять человек и три сервиса, сервер авторизации — лишняя инфраструктура. Хватит менеджера паролей и аккуратного отключения доступов при увольнении.

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