Во-первых, поймите, что кто-то где-то должен будет на самом деле подтвердить личность (как правило, запрашивая и проверяя пароль) «abc@testdomain.com» и т. Д. Что «кто-то» в общих чертах является поставщиком удостоверений или IdP. Во-вторых, обратите внимание, что, хотя вы указали SAML 2.0, я предполагаю, что вы также имеете в виду текущую (в 2018 году и сейчас) версию OpenID, «OpenID Connect»; предыдущие стандарты OpenID (до версии 1.2) очень разные, больше не поддерживаются и будут ниже «SAML» в «Должен ли я его поддерживать?» рейтинги.
Для пользователей, которых вы собираетесь поддерживать, у них уже есть настроенный IdP? Если да, то IdP не поддерживает OpenID Connect, а поддерживает SAML (или один из других менее распространенных стандартов SSO, таких как WS-Trust, CAS, Facebook Connect, Kerberos, так далее)? В этом случае и в этом случае только я бы пошел с SAML.
Если текущая IdP не настроена или IdP существует и IdP поддерживает OpenID Connect (OIDC), то сначала я бы пошел с поддержкой OIDC.
Очевидно, что если настроен IdP, и они не планируют или не хотят двигаться вперед с более новым, и , что IdP поддерживает только что-то "странное" например, CAS или Kerberos, вам придется внедрить этот стандарт с вашим сервисом вместо SAML или OIDC.
Как правило, OIDC набирает намного больше оборотов, чем SAML. Microsoft (Azure AD, ADFS), Google, Auth0, Ping и большинство других ведущих поставщиков IdP либо исключительно поддерживают OIDC, либо советуют использовать OIDC. Он имеет большую поддержку библиотек практически на всех языках. Это расширение наиболее часто используемой инфраструктуры авторизации API (OAuth 2.0). Это требует очень мало с точки зрения ухода и кормления. Если вы столкнетесь с проблемами при настройке поддержки проверяющей стороны OIDC, в сети появятся бесчисленные ресурсы по современным технологиям.
Напротив, SAML является сложным стандартом, который не имеет действительно хорошей поддержки библиотек и имеет тенденцию полагаться на технологии, которые вы, вероятно, не хотите использовать иначе (например, XML). Настройка и поддержка интеграции SAML отнимает много времени, особенно в том, что касается синхронизации сертификатов и их актуальности во всех системах. По моему личному опыту, когда вы можете найти помощь по настройке SAML, она часто будет устаревшей (не потому, что сама SAML изменилась, а потому, что все вокруг нее изменилось), поэтому вы должны иметь возможность переводить инструкции для, например, Windows 2008, к тому, что вы на самом деле используете сегодня. В общем, SAML имеет все признаки отклоняющейся технологии.
Как уже было сказано, SAML по-прежнему широко используется в некоторых областях, особенно в крупных компаниях или учреждениях (например, колледжах), которые сделали крупные инвестиции в SAML более 10 лет назад и не собираются возвращать эти инвестиции. Если вы работаете с ними, у вас есть несколько других вариантов.