Инициация SSO IdP vs Инициация SSO SP
Узнайте больше о различиях между IdP-инициированным SSO и SP-инициированным SSO и почему SP-инициированный SSO более безопасен.
Узнайте больше о различиях между IdP-инициированным SSO и SP-инициированным SSO и почему SP-инициированный SSO более безопасен.
Как следует из названия, SP-инициированное SSO инициируется провайдером услуг. Пользователь начинает процесс аутентификации, получая доступ к ресурсу на веб-сайте SP. SP затем перенаправляет пользователя к IdP для аутентификации. Как только пользователь аутентифицирован, IdP генерирует токен (OIDC) или утверждение SAML (SAML) и отправляет его обратно на SP. SP подтверждает токен или утверждение и предоставляет доступ пользователю.
В отличие от SP-инициированного SSO, IdP-инициированное SSO инициируется провайдером идентичности. Пользователь начинает процесс аутентификации с веб-сайта IdP. Обычно пользователь найдет список поддерживаемых приложений SP на портале IdP. Пользователь нажимает на приложение SP и перенаправляется на веб-сайт SP с уже аутентифицированной идентичностью.

IdP-инициированное SSO более популярно среди крупных предприятий и организаций, которые полагаются на различные сторонние приложения или сервисы, такие как Workday, Salesforce и т.д. Оно предоставляет централизованный способ управления доступом пользователей к множеству приложений и обеспечения аутентификации SSO. Позволяя IdP-инициированное SSO, сотрудники могут напрямую получить доступ к подключённым приложениям с портала IdP без необходимости посещать веб-сайт каждого приложения, сокращая время на онбординг и улучшая пользовательский опыт.
IdP-инициированное SSO несёт в себе больше рисков по сравнению с SP-инициированным SSO.
Отсутствие контекста аутентификации: Все запросы аутентификации, инициированные IdP, являются незапрашиваемыми. Таким образом, SP инициирует процесс аутентификации, потенциально открывая дверь для несанкционированного доступа. Есть риск, что пользовательская сессия может быть похищена. Злоумышленник может инициировать процесс входа для легитимного пользователя без его ведома или согласия.
Фиксация сессии: Поскольку SP не инициирует процесс аутентификации, пользовательская сессия может быть прикреплена к сессии IdP. Это может привести к атакам фиксации сессии, когда атакующий может привязать пользовательскую сессию к сессии IdP и получить несанкционированный доступ к учётной записи пользователя.
Фишинговые атаки: IdP-инициированное SSO может быть уязвимым для фишинговых атак. Злоумышленник может обмануть пользователя и заставить его посетить поддельный портал IdP и украсть учётные данные пользователя. Как только пользователь входит в систему, атакующий может перенаправить его на SP с предварительно аутентифицированной идентичностью.
Отсутствие уверенности в валидации запроса: В случае SP-инициированного SSO SP обычно включает необходимую информацию безопасности в запрос к IdP для поддержания целостности запроса. Как только SP получает ответ аутентификации, он проверяет эту информацию, чтобы предотвратить любые атаки CSRF. Например, параметр state в OIDC и RelayState в SAML. Однако в случае IdP-инициированного SSO SP не инициирует процесс аутентификации, и поэтому у него нет уверенности в проверке запроса.
IdP-инициированное SSO не поддерживается OIDC из-за вышеуказанных уязвимостей. OIDC требует, чтобы SP инициировал процесс аутентификации для обеспечения целостности запроса. Даже в случаях, когда пользователи начинают процесс аутентификации с третьих сторон, которые не являются SP, пользователь должен быть сначала направлен к SP для инициации процесса аутентификации.
Но в SAML IdP-инициированное SSO возможно. IdP может сгенерировать утверждение SAML без инициации SP процесса аутентификации. В SAML IdP-инициированном SSO утверждение SAML без правильного RequestID и RelayState может быть отправлено напрямую на URL ACS SP. SP должен быть в состоянии обработать подобное утверждение и предоставить доступ пользователю. (Примечание: Без RequestID и RelayState SP не имеет уверенности в целостности запроса).
Хотя IdP-инициированное SSO предоставляет централизованный способ управления доступом пользователей к нескольким приложениям, оно несёт в себе больше рисков по сравнению с SP-инициированным SSO. SP-инициированное SSO более безопасно и предоставляет больше уверенности в целостности запроса аутентификации. Рекомендуется использовать SP-инициированное SSO для обоих способов SSO на основе OIDC и SAML.