Большинство сравнительных статей о провайдерах идентификации написаны самими провайдерами. Удивительно, правда? Они перечисляют фичи, которые у них есть, умалчивают о том, чего нет, и называют это "объективным гидом".
Это не тот случай.
Мы изучили десятки реальных требований предприятий к IdP — настоящие таблицы и RFP-документы, которые команды закупок отправляют вендорам. Шаблон ясен: инженерные команды стабильно недооценивают самые важные критерии и переоценивают второстепенные.
Результат? Команды выбирают IdP по демо, через полгода обнаруживают, что миграция превратилась в кошмар, и начинают цикл оценивания заново.
Вот матрица оценки, которую мы бы сами хотели видеть до старта. Она создана для инженеров компаний B2B SaaS — тех, кто строит продукты, а не покупает SSO для сотрудников.
Коротко: что определяет выбор IdP#
Если ты листаешь бегло, вот суть:
- Глубина протокола важнее количества фич. Поддержка "OAuth2" ничего не значит. Какие grant types? Можно ли настраивать claims токена? Можно ли самому стать OIDC-провайдером?
- Возможность миграции — самый недооценённый критерий. Если ты не можешь мигрировать пользователей без обязательного сброса паролей — IdP непригоден, как бы привлекательно ни выглядело остальное.
- Многотенантность должна быть нативной, не прицепленной отдельно. Если модель организаций и настройки арендаторов требуют костылей — ты будешь воевать с системой навсегда.
- AI-готовность — не про далёкое будущее, а про требования ближайших 12 месяцев. Обмен токенами, идентификация агентов, делегированные скоупы. Если IdP не умеет это, через год вернёшься к пересмотру.
В остальной части гайда — разбор каждого измерения оценки с конкретными вопросами и типичными красными флагами.
Для кого этот гайд (и для кого — нет)#
Тебе полезно, если:
- Ты CTO, VP of Engineering или архитектор платформы в B2B SaaS (50-300 человек)
- У тебя 100 тыс.+ пользователей, миграция должна пройти без потрясений
- Ты идёшь в энтерпрайз, где клиенты требуют SSO, организационные модели и аудит-логи
- Нужно написать технический отчёт по оценке IdP без вендорских шаблонов
Это НЕ для тебя, если:
- Тебе нужен workforce IAM (SSO для сотрудников) — это отдельная категория
- У стартапа 500 пользователей и нет энтерпрайза — бери то, у чего лучший SDK, и не парься
- Нужна верификация личности (KYC/KYB) — вообще другая тема
Измерение 1: Возможности по протоколам — не просто "поддержка OAuth2"#
Любой IdP на рынке скажет, что поддерживает OAuth2 и OIDC. Это база. Суть — в деталях.
Grant types: какие нужны и почему это важно#
Обязательные:
- Authorization Code + PKCE — единственный поток для браузера и мобилок. Если вендор рекомендует Implicit flow — беги. PKCE не опционален — это безопасность.
- Client Credentials — для сервис-сервис коммуникации. Бэкенды должны аутентифицироваться друг с другом без пользователя.
- Refresh Token — звучит просто, но детали реализации разные. Можно ли задавать ротацию? Истечение? Можно ли ревокнуть конкретный refresh token, не убив всю сессию?
Всё важнее:
- Token Exchange (RFC 8693) — этот grant позволяет аутентификацию AI-агентов, потоки имперсонирования и делегирования. Если этого нет, спроси про дорожную карту. Нет дорожной карты — красный флаг.
Возможности OIDC-провайдера#
Вопрос, который редко задают: Может ли IdP быть самим OIDC-провайдером — не только потребителем?
Зачем: по мере роста SaaS-партнёры и клиенты захотят использовать твою идентификацию для входа в свои инструменты. Нужно выдавать токены, управлять consent, регистрировать сторонние приложения. Если IdP умеет только "поглощать" внешние IdP, но не работать в обратном направлении — ты упрёшься в потолок при федерации.
Вопросы:
- Есть ли у IdP OpenID Discovery endpoint, который можно брендировать?
- Можно ли регистрировать first-party и third-party приложения с разными trust-уровнями?
- Могут first-party приложения пропускать окно consent, а сторонние — требовать?
Кастомизация JWT#
Токен — контракт между IdP и сервисами. Если его нельзя настроить — любому микросервису придётся делать дополнительные API-запросы для авторизации.
Вопросы:
- Можно ли добавлять кастомные claims в access и ID токены?
- Можно ли внедрять контекст организации (в каком арендаторе сейчас пользователь) прямо в токен?
- Можно ли заводить собственные скоупы, мапящиеся на твою модель прав?
- Claims вычисляются при выдаче токена или можно динамически через webhook/скрипт?
Токен вида { "org_id": "org_123", "role": "admin", "auth_level": 2 } позволяет авторизовывать в middleware c одной строкой. { "sub": "user_456" } — заставит каждый сервис обращаться к IdP или базе. На больших объёмах разница — между 2 мс и 200 мс на запрос.
Измерение 2: Потоки аутентификации — детали, которые губят#
Любой IdP поддерживает email/password и социальный логин. Поздравляем, это... всё.
Различия кроются в деталях, не видимых на демо.
Процесс регистрации#
- Авто-вход после регистрации: Пользователь регистрируется — заходит сразу или его загоняет опять на логин-страницу? Форсить вход заново — минус конверсия. Очень много IdP делают это неправильно.
- Кастомные поля регистрации: Можно ли собирать роль, компанию или use case при регистрации? Или нужен отдельный flow сверху?
- Прогрессивное профилирование: Можно ли дособрать инфу частями, а не вываливать весь опрос в один шаг?
Процесс логина#
- Поддержка login_hint: Можно наперёд подставить email в логин из маркетинговой рассылки? Звучит просто. На деле — разница между 40% и 60% конверсии.
- Организационные политики аутентификации: Может ли организация A требовать SAML SSO, а B — email/password? Можно ли форсировать MFA только для enterprise арендаторов? Если для изменений политик по арендаторам нужен код, а не конфиг, сожжёшь много времени при каждом новом клиенте.
- Кастомизация брендинга: Настраивается ли логин per-tenant? Не только логотип-цвета, а полный CSS, кастомные домены и email-шаблоны. "Hosted UI vs. свой UI" — твой выбор, не ограничение IdP.
О чём забывают чек-листы#
- Silent authentication: По истечении токена можно незаметно обновить его без редиректа пользователя? Что если refresh token тоже протух — есть fallback (например, скользящая сессия через iframe)?
- Линковка аккаунтов: Человек зарегался через Google, потом попробовал логин по email. Это две учётки или одна? Как связывает IdP? Ошибёшься — будут дубли навсегда.
- Passwordless: Magic link, passkeys, WebAuthn. Не модная фича, а требование корпоратов через 6 месяцев.
Измерение 3: Сессии и токены — там, где тонко#
Здесь оценки перестают быть про демо. Session/token management — скучно пока не сломается. Когда ломается — вылетает вся база пользователей.
Безопасность cookie#
Не модно, но критично.
- HttpOnly, Secure, SameSite: Все три должны быть выставлены правильно. Если IdP не ставит HttpOnly на session cookie — он не продакшен-грейд.
- Кросс-субдоменная поддержка: Приложение на
app.yourproduct.com, API — на api.yourproduct.com. Сессии между ними работают?
- Уход третьесторонних cookie: Chrome их убивает. Как IdP решает cross-origin авторизацию без них? "Мы работаем над этим" — плохой ответ.
Remember me и долгие сессии#
Пользователи хотят быть залогиненными неделями. Но сессия 180 дней — это совсем другая безопасность по сравнению с 30 минутами.
Вопросы:
- Можно ли конфигурировать длительность сессии отдельно от жизни токена?
- Есть ли "remember me" при коротких токенах?
- Можно ли запросить повторную аутентификацию только для рискованных действий без убийства сессии?
Безопасность refresh токена#
- Ротация токена: IdP должен менять refresh token при каждом использовании.
- Шифрование: Refresh токены должны быть зашифрованы в базе.
- Гранулярность revocation: Можно ли убить только одну сессию на устройстве, не все?
- Гибкая экспирация: Можно ли задавать срок жизни refresh токена на приложение, а не глобально?
Измерение 4: Модель авторизации — не только базовый RBAC#
RBAC — база. Если IdP не поддерживает ролей, дальше не смотри. Но для B2B SaaS RBAC недостаточно.
Права на уровне организации#
Пользователи принадлежат организациям. Их права внутри каждой — отдельные.
Один пользователь может быть админом в Org A и зрителем в Org B. Не поддерживает IdP этот кейс — будешь строить свой парралельный контур, и два источника истины.
Вопросы:
- Можно ли задавать роли на уровне организаций, а не только пользователей?
- Может ли один пользователь иметь разные роли в разных организациях?
- Вшит ли текущий организационный контекст в токен, чтобы API понимал, в чьём контексте обращение?
Многоуровневая аутентификация (auth_level)#
Для финанcов, медицины, рискованных действий: не все сессии равны.
Смотреть дашборд — достаточно session cookie. Отправить платёж — нужно новое MFA даже если пользователь залогинен.
Это step-up authentication, требующая уровня аутентификации (auth_level) как части системы токенов.
Вопросы:
- Может токен нести claim
auth_level для проверки на бэкенде?
- Можно ли инициировать step-up из приложения без полного выхода?
- Есть ли свой срок жизни у
auth_level, не связанный с сессией?
Если IdP это не даёт — реализуешь сам, а ведь это тот функционал, ради которого нужен IdP.
Авторизация по токену#
Идеал: middleware читает токен, видит org, роль, auth_level — авторизует. Без запросов наружу.
Реал: многие IdP дают только user_id. Права — только черeз их API. Появляется лишний внешний вызов. 1,000 RPS превращается в сетьовую задержку.
Измерение 5: Миграция — определяющий критерий#
Неприятная статистика: большинство проектов по переходу на IdP рушатся не из-за недостатка фич, а из-за невозможности мигрировать пользователей.
100 тыс.+ юзеров — миграция не опция, а вся суть.
Три стратегии миграции (и какие IdP должен поддерживать)#
1. Массовый импорт с существующими hash паролями
Пароли хранятся в bcrypt, argon2 и т.д. Может ли IdP принять эти хэши и проверять пароли по ним?
Да: пользователи логинятся как раньше, ничего не чувствуют. Идеал.
Нет: всем приходит письмо "смените пароль". Потеряешь 30-50% базы. Это не теория.
2. Прогрессивная (ленивая) миграция
Пользователи мигрируются по ходу первого входа. Первый логин — старый сервис, успешная проверка — заводит юзера в новом IdP. Второй логин — уже в новом контуре.
Надёжно для больших систем, но требует:
- Кастомного хука аутентификации; обращение к легаси-системе
- Возможности создавать юзеров на лету при логине
- Учёта, кто уже мигрировал, а кто — нет
3. Dual-write (работа двух систем параллельно)
Пока мигрируешься, обе системы живы. Запись — сразу в обе, чтение — постепенно сдвигается на новую. Позволяет откатиться, но добавляет головную боль.
Красные флаги при миграции#
- "Мы поддерживаем CSV-импорт" — это только профиль, не пароли. Всё равно всем требуется сброс.
- "Есть гайд по миграции" — смотри детали. Если сказано "всем потребуется новый пароль" — это смерть половины активности.
- Нет упоминаний о поддерживаемых хэшах — значит, идёт только про демо, не про предприятия.
Вопросы#
- Какие алгоритмы паролей поддерживаются при импорте? (bcrypt, argon2, scrypt, PBKDF2, своё?)
- Можно строить прогрессивную миграцию по first login?
- Можно следить — какой процент пользователей уже мигрирован?
- Каков rollback, если что-то пошло не так?
- Можно сохранить непрерывность сессии, чтобы пользователи не вышли во время миграции?
Если вендор не отвечает сразу — у него не было заказчиков твоего масштаба. Иди дальше.
Измерение 6: Многотенантность — нативная или навесная#
B2B SaaS = многотенантность. Клиенты — организации с пользователями, ролями, политиками доступа. IdP должен уметь это по-настоящему.
Что значит "нативная многотенантность"#
- Организация — сущность первого порядка: Не кастомное поле у пользователя, а отдельная модель с id, настройками, членами.
- Политики аутентификации per org: Org A — SAML с корпоративным IdP, Org B — email+пароль + принудительный MFA, Org C — Google Workspace. Всё конфигурируется через UI/API.
- Инвайты и администрирование организации: Админы могут приглашать, задавать роли, удалять. IdP ведёт flow инвайта, верификацию email и назначение ролей.
- Токены с org-контекстом: Токен содержит организацию — API возвращает нужные данные.
У некоторых IdP нет нативной модели org. Предлагают хранить custom user metadata (user.app_metadata.org_id = "123").
Это очень быстро ломается:
- Один пользователь в нескольких org → сложные массивы
- Нет штатного flow инвайта или управления членством
- Нет политик per-org
- Нет org-токенов — контекст приходится извлекать обходными путями
- Аудит-логи не знают об организации
Вендор говорит "можно хранить org в metadata" — это как хранить отношения в JSON-поле. Пока мало юзеров — ок, потом — боль.
Вопросы#
- Модель организации в IdP — нативная или через user metadata?
- Может ли пользователь входить в несколько организаций одновременно?
- Можно ли настраивать разные требования к аутентификации per org?
- Есть ли штатные org-роли и права?
- Могут админы управлять членством через self-service UI?
- Включает ли токен контекст организации?
Измерение 7: AI-готовность — критерий из будущего#
Год назад "аутентификация AI-агентов" не обсуждалась нигде. Сейчас, если ты внедряешь AI-фичи (копилоты, агенты, workflow) — понадобится новый тип идентификации: агент.
Почему агенты рушат стандартную схему#
Обычная аутентификация — два игрока: пользователь и приложение (OAuth2 так задуман).
AI-агенты — третий: не человек, а сущность, действующая от лица пользователя и требующая аудита.
- Агент — не пользователь: нет пароля или браузерной сессии
- Агент — не M2M: действует по поручению конкретного пользователя
- Агенты нуждаются в ограниченных, временных правах
Что IdP должен уметь#
Token Exchange (RFC 8693): Агент предъявляет свой credential + разрешение пользователя и получает токен с нужным скоупом. В токене — кто (user), кто действует (agent), какие права (scope), когда действует (expiration).
Agent как клиент: Агент — отдельный OAuth2 клиент с уникальным client_id, не кость через API-ключи или user-токены.
Делегирование скоупов: Пользователь может разрешить агенту только часть доступа — читать, но не писать, к конкретным ресурсам.
Аудит: Логи должны различать "user сделал X" и "agent сделал X за пользователя". Не отличаешь — не проходишь SOC2, аудиторы спросят кто именно.
Совместимость с MCP (Model Context Protocol)#
MCP становится стандартом взаимодействия AI-агентов с сервисами. Если IdP умеет OAuth-аутентификацию для MCP-серверов — агенты правильно проходят идентификацию на уровне протокола, не через ключи.
Вопросы#
- Поддерживается ли OAuth2 Token Exchange?
- Можно ли моделировать агентов как отдельные client types?
- Несёт ли токен делегированные права (кто разрешил агенту, с каким scope)?
- Различаются ли действия агентов и людей в аудит-логах?
- Есть ли интеграция с MCP или OAuth для agent-to-tool?
Если об этом не думали — они строят для 2020. Ты готовишься к 2026.
Измерение 8: Нефункциональные требования — то, что волнует по ночам#
Фичи продают IdP. Операционные детали решают вопрос пролонгации контракта.
Производительность#
- Пропускная способность аутентификации: Система выдерживает 100+ auth-запросов в секунду в пике? А если 1,000+?
- Латентность валидации токенов: Если сервисы валидируют JWT локально (так и нужно), то это микросекунды. Если нужно introspection — какой P99 задержки?
- Потолок масштабируемости: Максимальное число Monthly Active Users? Есть ли реальные кейсы на твоём масштабе?
Соответствие стандартам#
- SOC2 Type II: Не Type I! Type II — результат многомесячного аудита, а не просто точечная проверка. Есть только Type I — спроси, когда будет Type II.
- Аудит-логи: Все события аутентификации, изменение прав, действия админов — логируются. Можно ли экспортировать их в SIEM? Логи неизменяемые?
- Хранение данных: Можно ли выбирать регион хранения пользовательских данных? Для клиентов из ЕС — не обсуждается.
Надёжность#
- SLA по аптайму: 99.9% — вроде круто, но это 8,7 часа простоя в год. 99.99% — 52 минуты. Для аутентификации — ощутимая разница.
- Failover: Что происходит при сбое IdP? Есть ли резервные механизмы? Мульти-региональная схема?
- История инцидентов: Смотри статус-пейдж — не обещания, а факты.
Переносимость данных#
- Экспорт пользователей: Можно ли выгрузить всех пользователей с метаданными, организациями, ролями? В каком формате?
- Cтандарты: Используют ли стандартные протоколы (OIDC, SCIM) — можно ли легко мигрировать на другой IdP?
- Отсутствие lock-in: Проприетарные API, нестандартные форматы токенов, закрытые протоколы — всё это красные флаги. Чем больше стандартов — тем проще сменить IdP потом.
Матрица оценки: практическая система баллов#
Провёл сравнение — нужно как-то сопоставить варианты. Вот фреймворк приоритетов:
P1 — Критически важно (факт не прохождения = дисквалификация)#
| Критерий | Почему P1 |
|---|
| Импорт хэшей паролей или прогрессивная миграция | Без этого невозможно мигрировать |
| Authorization Code + PKCE | Базовый уровень безопасности |
| Нативная модель организаций | Требование для B2B SaaS |
| SOC2 Type II (или чёткий план по нему) | Обязательно для энтерпрайзов |
| SLA аптайм 99.9%+ | Auth down = весь продукт отвалился |
P2 — Очень желательно (если нет — перерасход ресурсов)#
| Критерий | Почему P2 |
|---|
| Кастомные claims JWT | Не нужно делать lookup на каждый запрос |
| Персональные политики аутентификации per org | Требования энтерпрайзов при внедрении |
| Роли и токены на уровне организации | Авторизация в multi-tenant |
| Ротация и revocation refresh токенов | Требование безопасности |
| Hosted UI + кастомный UI | Гибкость под кейсы бизнеса |
P3 — Важно (закладывать на 12 месяцев вперёд)#
| Критерий | Почему P3 |
|---|
| Token Exchange (RFC 8693) | AI-агенты |
| OIDC-провайдер | Партнёрская федерация |
| Step-up authentication / auth_level | Финансы/рискованные операции |
| SCIM | Интеграция с каталогами клиентов |
| Passkey/WebAuthn | Passwordless-аутентификация |
P4 — Приятно иметь (не тормозит выбор)#
| Критерий | Почему P4 |
|---|
| Строенный analytics dashboard | Можно собрать из аудит-логов |
| Белые email-шаблоны | Просто удобно |
| Визуальный flow builder | Просто удобно |
| Социальные коннекторы (кроме топ-5) | Длинный хвост интеграций |
Как пользоваться: Начинай с P1. Не прошёл — исключай. Затем сравнивай по P2 и P3 баллам. Лучший результат — лучший кандидат.
Частые ошибки оценки#
Команды наступают на одни и те же грабли. Вот как их избежать:
Ошибка 1: Оценка только фичами, а не архитектурой#
Таблица фич — это список галочек. Но не понимает, как реализовано. Например, IdP поддерживает организации — просто пишет org_id в user metadata. В демо это секси, но в проде — постоянная боль.
Что делать: Всегда спрашивай: "как реализовано?" — не только "есть ли?"
Ошибка 2: Забыть о миграции до выбора#
Команда выбрала "лучший" IdP, сделала интеграцию и поняла, что не может мигрировать юзеров без массовой рассылки по смене паролей. В итоге — или плохая миграция, или пересмотр проекта.
Что делать: Миграция — фильтр №1, а не последний.
Ошибка 3: Упор на демо#
Демо — это идеальный путь, чистая база, ни одной аномалии. В проде всё иначе: сросшиеся аккаунты, unicode в полях, висящие сессии...
Что делать: Договаривайся на PoC с реальными данными. Возьми 1,000 пользователей, прогоняй свои флоу.
Ошибка 4: Нет всех нужных участников#
Оценивает только платформа — выберет идеально чисто, но нереально для интеграции. Только продукт — только простота встраивания. Только безопасность — только чекбоксы.
Что делать: В оценке минимум — инженеры платформы, продукт, безопасность. У каждого — свои зоны по P1/P2.
Ошибка 5: Забыл, что придётся уходить#
Вендорский lock-in реален. Свой SDK, свои API, уникальный токен — всё усложняет последующую миграцию.
Что делать: По возможности — только стандартные протоколы (OIDC, OAuth2, SCIM). Это благодарность твоему будущему "я."
FAQ#
Сколько занимает полноценная оценка IdP?#
На полный процесс с PoC закладывай 4-8 недель. Спешка увеличивает риск ошибок — особенно с миграцией. Две недели на сбор требований, 2–3 недели на сравнение и PoC, 1–2 недели на согласование.
Стоит ли строить свой auth?#
Зависит от стадии. Если до 10 тыс. пользователей и нет энтерпрайза — хватит и легаси-библиотеки. Но как только появляется SSO, многотенантность, MFA и compliance, стоимость поддержки своего решения догоняет и обгоняет SaaS-IdP. Часто это 2–3 инженера full-time, $300–500 тыс./год.
Чем отличается CIAM от workforce IAM?#
Customer IAM (CIAM) — то, что видят клиенты: регистрация, логин, профиль. Workforce IAM — то, чем сотрудники входят во внутренние системы (Slack, Google Workspace и т.д.). Покупаются по-разному. Гайд — только про CIAM.
Open Source против проприетарности — что важнее?#
Open source — прозрачность (можно проверять код), переносимость (можно хостить у себя), вклад коммьюнити. Проприетарные решения часто с лучшим UI и управляймым сервисом. Важно не "open/закрытость", а "можно ли уйти, если надо". Open source проще по переносимости: модель и API открыты.
Когда AI-агенты должны быть P1, а не P3?#
Если уже строишь AI, который работает от имени пользователей (копилоты, сценарии, ассистенты) — сразу P1. Если AI на горизонте 6–12 мес. — держи в P3, но с большим весом. Если AI не планируется — пусть останется P4, но пересмотри через полгода.
Как сравнивать цены при разных моделях вендоров?#
Обычно считаются MAU — Monthly Active Users, но тут много подводных камней: кто-то считает каждый логин, кто-то уникальных пользователей, кто-то отдельно M2M токены. Проси просчитать твой конкретный сценарий: X пользователей, Y организаций, Z M2M, N auth-запросов. Сравнивай итоговую сумму, а не цену за юнита.
Главное#
Выбор провайдера идентификации — инфраструктурное, а не фичевое решение. Ты делегируешь ему первый контакт каждого пользователя, каждую авторизацию, каждый audit для compliance-команды.
Матрица выше — то, что важно на самом деле, не то, что идёт в маркетинг-материалах. Используй её для быстрой фильтрации (сначала P1), глубокой проверки (P2+P3 с PoC) — и выбирай на годы, не месяцы.
Общие черты успешных команд — они относятся к identity как к инфраструктуре, а не как к одной из фич.
