Как внедрить SSO в B2B-сервис и не потерять управляемость доступами

Сначала проверьте, решает ли SSO вашу задачу

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

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

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

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

SSO подтверждает, кто вошёл в систему. Продукт всё равно должен решить, что этому человеку разрешено делать в конкретной организации.

Разделите вход, организацию и права на действия

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

Ошибка — превращать роль из корпоративного каталога в единственный источник продуктовых прав. Название должности или группы в каталоге клиента редко в точности соответствует действиям в сервисе. Лучше принимать от провайдера устойчивый идентификатор пользователя и, при необходимости, группы, а в продукте поддерживать собственные роли и разрешения. Например, группа клиента может дать базовый доступ, но право на утверждение платежей должно назначаться по правилам организации и оставаться проверяемым в журнале.

В мультиарендной системе это также защищает от смешения данных. Каждый запрос к API должен исполняться в контексте организации, а не только пользователя. Идентификатор организации нельзя без проверки принимать из параметра браузера или мобильного приложения: сервер обязан сверить членство пользователя и право на конкретное действие. Для сложных процессов полезно сначала описать объекты, состояния и ответственных — этот подход раскрыт в материале про <a href="/blog/b2b-system-design">проектирование сложной B2B-системы</a>.

• Храните неизменяемый идентификатор пользователя от провайдера, а не используйте email как единственный ключ.
• Проверяйте права на сервере для каждого чувствительного API-метода, включая экспорт, массовые операции и администрирование.
• Явно моделируйте связь «пользователь — организация — роль», если один специалист работает с несколькими клиентами.

Выберите протокол и жизненный цикл учётной записи до начала интеграции

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

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

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

• OpenID Connect выбирают для современной федеративной авторизации, SAML — когда его требует существующая корпоративная среда клиента.
• SCIM нужен не для входа, а для управляемого создания, обновления и отключения пользователей.
• Для каждого клиентского контура фиксируйте issuer, идентификатор приложения, разрешённые домены, сертификаты или ключи и контакт ответственного администратора.

Сделайте путь входа понятным для сотрудника и безопасным для администратора

На экране входа пользователю не нужно выбирать технический протокол. Достаточно понятного маршрута: ввести рабочий email, выбрать организацию при нескольких доступных контурах или перейти по корпоративной ссылке. После возврата из провайдера покажите не абстрактную ошибку авторизации, а следующее действие: «обратитесь к администратору организации», «у вас нет доступа к этому разделу» или «повторите вход после подключения к корпоративной сети». При этом текст не должен раскрывать постороннему человеку, существует ли конкретная учётная запись.

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

Многофакторная аутентификация обычно должна оставаться политикой корпоративного провайдера, поскольку именно там клиент управляет устройствами, методами подтверждения и рисками. Сам продукт может требовать повторное подтверждение для особо чувствительных действий, но нельзя считать, что повторный запрос пароля решает задачу защиты. Требования к проверкам доступа, сессиям и ошибкам полезно сверять с <a href="https://owasp.org/www-project-application-security-verification-standard/">OWASP Application Security Verification Standard</a>.

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

Запускайте SSO как контролируемую интеграцию и измеряйте не только успешный вход

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

Тестировать нужно не только браузерный экран. Проверьте API: нельзя ли вызвать метод другой организации с действующей сессией, не принимает ли сервер неподписанный или просроченный токен, не позволяет ли ссылка возврата увести пользователя на чужой домен. Риски вокруг объектов, аутентификации и избыточных разрешений систематизированы в <a href="https://owasp.org/API-Security/">OWASP API Security Top 10</a>. Если SSO связывается с другими корпоративными системами, заранее определите владельцев данных и правила обработки сбоев — они описаны в статье про <a href="/blog/product-integrations-data-boundaries">правила проектирования интеграций и границ данных</a>.

После включения следите за долей неуспешных входов по причинам, временем до первого успешного входа, числом ручных восстановлений, случаями отказа в правах и задержкой между изменением в каталоге и изменением доступа в продукте. Эти данные не заменяют аудит: для чувствительных действий сохраняйте, кто выполнил операцию, в какой организации, с какой ролью, когда и каким способом прошёл проверку. Если задача затрагивает несколько контуров доступа, API и внутренние процессы, её стоит вынести на техническую проработку в направлении <a href="/services/enterprise">корпоративных систем и интеграций</a>.

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