Что такое провайдер идентичности (IdP)

Провайдер идентичности (Identity Provider, IdP) — сервис, который хранит учётные записи, проверяет личность пользователей и сообщает приложениям результат этой проверки.

Идея в разделении обязанностей. Приложение занимается своей задачей — отчётами, продажами, документооборотом — и не берёт на себя хранение паролей, реализацию второго фактора и управление сессиями. Всё это делает провайдер, а приложение доверяет его вердикту.

Две стороны обмена

Провайдер идентичности (IdP) проверяет пользователя и выпускает подтверждение.

Приложение (Service Provider) предоставляет функциональность и полагается на подтверждение провайдера, не проверяя учётные данные самостоятельно.

Пользователь взаимодействует с обоими: работает в приложении, а вход проходит у провайдера.

Что делает провайдер

Хранит учётные записи. Идентификаторы, хешированные пароли, привязанные факторы аутентификации, принадлежность к организациям и группам.

Проверяет личность. Пароль, одноразовый код, passkey — в зависимости от настроенной политики.

Выпускает токены. Подтверждение того, что пользователь опознан, в формате, понятном приложениям.

Управляет сессиями. Знает, какие сессии активны, и умеет их завершать.

Ведёт журнал. Фиксирует входы, отказы, изменения прав — материал для разбора инцидентов и проверок.

Применяет политики. Требование второго фактора, ограничения по устройствам или адресам, время жизни сессии.

Зачем выносить это из приложения

Пароли в одном месте. Утечка базы приложения не раскрывает пароли, потому что их там нет.

Второй фактор внедряется однократно. Настроенный у провайдера, он действует во всех подключённых приложениях без изменения их кода.

Отзыв доступа одним действием. Отключение учётной записи закрывает все приложения сразу — не нужно обходить каждое.

Единый журнал. Все входы проходят через одну точку, поэтому картина доступа целостна.

Быстрое подключение новых приложений. Логика входа не пишется заново каждый раз.

Типы провайдеров

Корпоративные обслуживают сотрудников: интеграция с оргструктурой, роли, политики компании.

Клиентские (CIAM) рассчитаны на внешних пользователей: самостоятельная регистрация, восстановление доступа, масштаб в сотни тысяч учётных записей.

Социальные позволяют входить через существующие аккаунты в публичных сервисах. Удобно для массовых продуктов, но передаёт контроль над доступом внешней стороне.

Каталожные работают поверх корпоративного каталога и типичны для внутренних сетей.

Многие организации используют несколько сразу: собственный провайдер для сотрудников и подключение внешних для отдельных категорий пользователей.

На что смотреть при выборе

Поддержка стандартов. OIDC и OAuth 2.0 — необходимый минимум. Проприетарный протокол означает зависимость от поставщика и трудности с интеграцией.

Способы аутентификации. Наличие passkeys, а не только SMS-кодов, определяет, сможете ли вы защититься от фишинга.

Управление сессиями. Возможность увидеть активные сессии и завершить конкретную — то, без чего реагирование на инцидент превращается в смену пароля и надежду.

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

Журналирование. Наличие журнала с реальными адресами пользователей, а не адресами внутренних прокси.

Гибкость ролевой модели. Возможность описать права так, как устроена ваша организация.

Как это устроено в Keydee

Keydee — провайдер идентичности для ваших приложений и ваших клиентов.

• Подключение по OIDC: приложение регистрируется, получает идентификатор и секрет, настраивает адреса перенаправления.
• Мультиарендность: компании изолированы, пользователь одной организации не получает доступа к данным другой.
• Аутентификация: пароль, TOTP, passkeys; требование второго фактора задаётся политикой компании.
• Роли и права описываются в границах организации и передаются приложениям в токене.
• Управление сессиями: активные сессии видны, любую можно завершить — доступ прекращается сразу, включая выданные с этого устройства разрешения.
• Уведомление приложений о выходе: подключённые приложения узнают о завершении сессии и закрывают её у себя.
• Журнал событий с фиксацией реального IP-адреса пользователя.

Что стоит понимать

Провайдер идентичности становится системой первой категории важности. Если он недоступен — не работает вход во все приложения сразу. Если он скомпрометирован — скомпрометировано всё.

Это не аргумент против централизации: разрозненные пароли в двадцати системах хуже по всем параметрам. Это аргумент за то, чтобы относиться к провайдеру соответственно: обязательный второй фактор для администраторов, контроль журналов, продуманный сценарий недоступности.