SAML и OIDC - два самых популярных протокола аутентификации, используемых в индустрии единого входа (SSO). Эта статья сравнит SAML и OIDC с точки зрения их архитектуры и применения.
SimengDeveloper
Хватит тратить недели на аутентификацию пользователей
Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.
SAML (Security Assertion Markup Language) - это открытый стандарт на основе XML для обмена данными аутентификации и авторизации между различными сторонами, в частности, между поставщиком идентификационных данных (IdP) и поставщиком услуг (SP).
Он позволяет реализовать веб-основанный SSO (единого входа), позволяя пользователям один раз аутентифицироваться для доступа к нескольким приложениям. SAML - это зрелый протокол, существующий уже давно и широко принятый предприятиями. Некоторые из самых популярных SaaS платформ, такие как Salesforce, Workday и Microsoft Azure AD, поддерживают SAML SSO.
Поставщик идентификационных данных (IdP): Сущность, которая аутентифицирует пользователей и предоставляет информацию о личности поставщикам услуг.
Поставщик услуг (SP): Сущность, которая предоставляет услуги пользователям и полагается на поставщика идентификационных данных для аутентификации пользователей.
SAML утверждения: Документы на основе XML, которые содержат детали аутентификации и авторизации пользователя, включая утверждения аутентификации, атрибутивные утверждения и решения об авторизационном утверждении.
Протокол SAML: Определяет формат сообщений и правила обмена SAML утверждениями между IdP и SP.
SAML связывания: Определяет, как SAML сообщения транспортируются по различным протоколам связи, как HTTP POST, HTTP Redirect и т.д.
Метаданные SAML: Документы на основе XML, которые содержат информацию о конфигурации IdP и SP. Включает публичный ключ, конечные точки и поддерживаемые связывания, используемые для установления доверия между IdP и SP.
Конечная точка единого входа: Конечная точка, где SP перенаправляет пользователя для аутентификации через IdP.
URL службы потребления утверждений (ACS): Конечная точка, куда IdP отправляет SAML утверждение после успешной аутентификации.
Зрелый и широко принятый: SAML - зрелый протокол, который существует уже давно и широко принят предприятиями.
Стандартизированный: SAML - открытый стандарт, поддерживаемый OASIS, обеспечивающий совместимость между различными поставщиками.
SSO: SAML позволяет реализовать веб-основанный SSO, чтобы пользователи могли один раз аутентифицироваться для доступа к нескольким приложениям.
Централизованное управление пользователями: SAML позволяет организациям централизованно управлять пользователями и последовательно применять политики безопасности.
Сложность: SAML - сложный протокол, требующий глубокого понимания XML и концепций безопасности.
Производительность: Сообщения SAML основаны на XML и могут быть большими. Доставка и разбор XML могут быть медленнее по сравнению с форматами токенов, такими как JSON Web Token (JWT).
Устаревший стандарт: SAML - старший стандарт по сравнению с OIDC и считается менее безопасным.
Привязанность к поставщику: SAML - специфический для поставщика протокол, и переход между поставщиками может быть сложным.
OIDC (OpenID Connect) - это слой идентификации, построенный поверх протокола OAuth 2.0. Подобно SAML, OIDC также используется для обмена данными аутентификации и авторизации между IdP и SP.
По сравнению с SAML, OIDC - более современный и легковесный протокол, который приобретает популярность для современных веб-и мобильных приложений. OIDC использует JWT для передачи информации об идентификации, что более компактно и проще в работе по сравнению с утверждениями на основе XML SAML. Он особенно популярен для приложений, ориентированных на потребителя, и безопасности API.
Поставщик идентификационных данных (IdP): Сущность, которая аутентифицирует пользователей и предоставляет информацию о личности поставщикам услуг.
Пользовательская сторона (RP): Сущность, которая предоставляет услуги пользователям и полагается на поставщика идентификационных данных для аутентификации пользователей. Например, веб-приложения, мобильные приложения или API.
Токены OIDC: Токены, которые содержат информацию о личности пользователя.
ID токен: Токен формата JWT, содержащий информацию о личности пользователя.
Access токен: Токен формата JWT или непрозрачного формата, который предоставляет доступ к защищенным ресурсам.
Refresh токен: Токен, используемый для получения нового access токена без требования переаутентификации пользователя. Он предоставляет оффлайн долгосрочный авторизационный доступ к RP.
Конечные точки OIDC: Конечные точки, используемые для аутентификации и обмена токенами. Некоторые из самых важных конечных точек:
Конечная точка обнаружения: Где RP может получить публичную конфигурационную информацию OIDC от IdP.
Конечная точка авторизации: Где RP отправляет запрос на аутентификацию.
Конечная точка токенов: Где RP запрашивает у сервера авторизации токены.
Конечная точка информации о пользователе: Где RP может получить информацию о профиле пользователя.
Объемы: OIDC определяет набор стандартных объемов, которые определяют права доступа, предоставленные RP. Например, openid, profile, email, address и т.д.
Современный и легковесный: OIDC - современный протокол, который использует JSON-носители JWT токены, которые более компактны и проще в обработке по сравнению с основанными на XML утверждениями SAML.
Приложения, ориентированные на потребителей: OIDC особенно популярен для приложений, ориентированных на потребителей, и безопасности API.
Совместимость: Построенный на основе OAuth 2.0, OIDC совместим с различными платформами, устройствами и платформами.
Безопасность: OIDC предлагает более безопасный метод аутентификации пользователей и защиты API. Он включает в себя различные современные функции безопасности, такие как introspection токена, отозвание токенов, Proof Key for Code Exchange (PKCE) и поддерживает различные потоки аутентификации, адаптированные к различным потребностям безопасности.
Простота использования: OIDC проще в реализации и работе по сравнению с SAML. Он более дружественен к разработчикам и имеет обширные библиотеки и SDK для множества языков программирования и платформ.
Управление токенами: OIDC полагается на токены для аутентификации и авторизации. Это требует надлежащих практик управления токенами для обеспечения безопасности.
Сложность: Хотя OIDC прост для базовых настроек, из-за своей гибкости он может добавить сложности при реализации сложных настроек. Например, собственные утверждения и Управление доступом на основе ролей (RBAC) и т.д.
Принятие: OIDC все еще относительно новый по сравнению с SAML, особенно в корпоративной среде. Некоторые устаревшие системы могут по-прежнему полагаться на SAML для целей SSO.
Оба SAML и OIDC широко используются для целей аутентификации и авторизации.
SAML остается основой для корпоративного единого входа и интеграции B2B. Его надежная поддержка управления федеративной идентичностью и проверенная временем история обеспечивают его непреходящую значимость, особенно для устаревших систем и крупных организаций.
OIDC, с другой стороны, продолжает развиваться под влиянием требования к безопасности и масштабируемости аутентификации в современных приложениях. Его легковесная природа и совместимость с API и микросервисами делают его основой для облачных и распределенных архитектур. С ростом популярности безпарольной аутентификации, биометрии и многофакторной аутентификации (MFA), OIDC, вероятно, интегрируется с новыми технологиями, обеспечивая его актуальность на ближайшие годы.