Что такое единый вход (SSO) и когда он нужен вашему SaaS

Что означает SSO в деловом контексте

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

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

Чем это отличается от того, с чем его путают

Вход через соцсети — с личным аккаунтом Google, Microsoft или GitHub — выглядит для пользователя похоже и для покупателя устроен иначе. Идентичность принадлежит человеку, а не компании, поэтому администратору она не даёт никакого контроля и не прекращается вместе с трудовым договором. Это хорошая функция для конверсии и не замена корпоративному SSO.

Провижининг — тоже отдельная вещь. SSO отвечает на вопрос, кто входит; провижининг создаёт, обновляет и отключает учётные записи в вашем продукте в соответствии с каталогом компании, обычно через SCIM. Покупатели часто просят и то и другое под одним названием. Стоит прямо говорить, что именно вы поддерживаете, потому что компания с SSO, но без провижининга всё равно вынуждена удалять ушедших из вашего продукта вручную.

Протоколы, коротко

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

Когда пора это строить

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

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

Во что это обходится после запуска

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

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