Как выбрать провайдера идентификации: оценочная матрица для инженерной команды

Большинство сравнительных статей о провайдерах идентификации написаны самими провайдерами. Удивительно, правда? Они перечисляют фичи, которые у них есть, умалчивают о том, чего нет, и называют это "объективным гидом".

Это не тот случай.

Мы изучили десятки реальных требований предприятий к IdP — настоящие таблицы и RFP-документы, которые команды закупок отправляют вендорам. Шаблон ясен: инженерные команды стабильно недооценивают самые важные критерии и переоценивают второстепенные.

Результат? Команды выбирают IdP по демо, через полгода обнаруживают, что миграция превратилась в кошмар, и начинают цикл оценивания заново.

Вот матрица оценки, которую мы бы сами хотели видеть до старта. Она создана для инженеров компаний B2B SaaS — тех, кто строит продукты, а не покупает SSO для сотрудников.

Коротко: что определяет выбор IdP#

Если ты листаешь бегло, вот суть:

1. Глубина протокола важнее количества фич. Поддержка "OAuth2" ничего не значит. Какие grant types? Можно ли настраивать claims токена? Можно ли самому стать OIDC-провайдером?
2. Возможность миграции — самый недооценённый критерий. Если ты не можешь мигрировать пользователей без обязательного сброса паролей — IdP непригоден, как бы привлекательно ни выглядело остальное.
3. Многотенантность должна быть нативной, не прицепленной отдельно. Если модель организаций и настройки арендаторов требуют костылей — ты будешь воевать с системой навсегда.
4. 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 возвращает нужные данные.

"Кастомные metadata" — путь в никуда#

У некоторых 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 — Критически важно (факт не прохождения = дисквалификация)#

P2 — Очень желательно (если нет — перерасход ресурсов)#

P3 — Важно (закладывать на 12 месяцев вперёд)#

P4 — Приятно иметь (не тормозит выбор)#

Как пользоваться: Начинай с 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 как к инфраструктуре, а не как к одной из фич.