Единый вход (SSO)

Single Sign-On (SSO), или единый вход — это схема аутентификации, которая позволяет пользователю войти один раз через центрального провайдера идентификации (IdP) — например, Okta, Azure AD/Entra ID, Google Workspace или OneLogin — и получить доступ к нескольким подключённым приложениям, не вводя учётные данные заново для каждого. Технически SSO реализуется через один из двух доминирующих протоколов: SAML (Security Assertion Markup Language) — более старый, но всё ещё корпоративный стандарт на основе XML, и OpenID Connect (OIDC) — современный слой на JSON/JWT, построенный поверх OAuth 2.0. Когда пользователь пытается зайти в ваше SaaS-приложение, оно (являясь «поставщиком услуги», service provider) перенаправляет его к IdP компании; IdP проверяет личность пользователя (сверяя корпоративные учётные данные, возможно с MFA) и отправляет обратно подписанное утверждение (assertion) или токен, подтверждающий, кто это; ваше приложение доверяет этому утверждению и создаёт сессию — ни разу не увидев реальный пароль пользователя. SSO критически важен для B2B SaaS-разработчиков, поскольку часто является жёстким требованием закупки для сделок среднего и корпоративного сегмента — компания с 500 сотрудниками не позволит вендору управлять 500 отдельными паролями, как по соображениям безопасности (централизованный отзыв доступа при увольнении сотрудника), так и по требованиям соответствия (см. SOC 2). Многие SaaS-вендоры теперь взимают за SSO отдельную плату («SSO-налог») именно потому, что корпоративные покупатели готовы платить за это премию. Конкретный пример: сотрудник Acme Corp нажимает «Войти через SSO» в вашем приложении и вводит email `jane@acmecorp.com`. Ваше приложение находит настроенные SAML-метаданные Acme Corp, перенаправляет на `https://acmecorp.okta.com/app/yourapp/sso/saml`, Джейн аутентифицируется через Okta (в которую она уже была залогинена), и Okta отправляет POST-запросом подписанное SAML-утверждение на Assertion Consumer Service URL вашего приложения. Ваш бэкенд проверяет подпись по публичному сертификату Okta, извлекает из утверждения email Джейн и её принадлежность к группам, и создаёт сессию — и всё это без того, чтобы ваше приложение хоть раз сохранило или увидело пароль Джейн. SSO также лежит в основе ещё одного корпоративного требования, которое разработчикам стоит закладывать заранее — провижининга SCIM (System for Cross-domain Identity Management), который позволяет IdP клиента автоматически создавать, обновлять и деактивировать учётные записи пользователей в вашем приложении в момент, когда сотрудник присоединяется к компании или покидает её — закрывая брешь в безопасности, при которой доступ уволенного сотрудника к стороннему SaaS-инструменту сохраняется просто потому, что никто не вспомнил отозвать его вручную. Провайдеры аутентификации вроде Okta, Auth0 и WorkOS существуют именно для того, чтобы небольшие SaaS-команды могли подключить корпоративную поддержку SSO/SCIM, не реализуя обработку SAML/OIDC с нуля.