Что такое OpenID Connect (OIDC) и как он работает

OpenID Connect (OIDC) — это протокол аутентификации, который позволяет приложению узнать, кто именно к нему пришёл, не храня у себя паролей. Пользователь входит через доверенный провайдер идентичности, а приложение получает подписанный ID-токен — подтверждение личности в машиночитаемом виде.

Если коротко: OAuth 2.0 отвечает на вопрос «что этому приложению разрешено делать», а OIDC добавляет ответ на вопрос «кто этот пользователь».

Зачем это нужно

Классическая схема, где каждое приложение хранит собственную таблицу пользователей и паролей, плохо масштабируется. Растёт число мест, где может утечь пароль. Отзыв доступа при увольнении сотрудника превращается в обход десятка систем. Двухфакторную аутентификацию приходится встраивать в каждое приложение отдельно.

OIDC решает это переносом аутентификации в одну точку:

• пароли живут только у провайдера идентичности, приложения их не видят;
• вход в новое приложение не требует новой учётной записи;
• MFA, политики паролей и журналирование настраиваются централизованно;
• сессию можно завершить сразу во всех приложениях.

Ключевые участники

Провайдер идентичности (IdP) — сервис, который проверяет учётные данные и выпускает токены. В вашей инфраструктуре эту роль выполняет Keydee.

Клиент (relying party) — приложение, которое хочет узнать пользователя: веб-панель, мобильное приложение, внутренний сервис.

Пользователь — сотрудник, партнёр или клиент, который проходит вход.

Токены — результат успешной аутентификации. Их три вида:

Токен	Что означает	Кому адресован
ID-токен	Кто пользователь: идентификатор, email, время входа	Клиентскому приложению
Access-токен	Что разрешено делать	API и защищённым ресурсам
Refresh-токен	Право продлить сессию без повторного входа	Клиенту, хранится защищённо

Как проходит вход: пошагово

1. Пользователь нажимает «Войти». Приложение перенаправляет его на Keydee.
2. Keydee проверяет учётные данные — пароль, одноразовый код, passkey — по политике вашей компании.
3. После успешной проверки Keydee возвращает приложению временный код авторизации.
4. Приложение обменивает код на токены, обращаясь к серверному эндпоинту. Этот обмен происходит между серверами, минуя браузер.
5. Приложение проверяет подпись токена, издателя, получателя и срок действия.
6. Доступ предоставлен.

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

Потоки авторизации

Authorization Code Flow — основной выбор

Тот самый поток, описанный выше. Токены никогда не попадают в адресную строку, а обмен кода происходит на сервере.

Когда использовать: практически всегда. Для веб-приложений с бэкендом — в чистом виде, для мобильных и SPA — с расширением PKCE, которое защищает от перехвата кода на устройстве.

Implicit Flow — устаревший

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

Когда использовать: не использовать. Современная замена — Authorization Code с PKCE.

Hybrid Flow — для особых случаев

Часть токенов приходит сразу, часть — после обмена кода. Нужен редко, обычно при интеграции со старыми системами, которым требуется ID-токен на самом раннем шаге.

OIDC, OAuth и SAML: чем отличаются

Эти три протокола часто путают, хотя решают они разные задачи.

OAuth 2.0 — про делегирование доступа. Он позволяет приложению действовать от имени пользователя, но ничего не говорит о том, кто этот пользователь. Использовать OAuth как способ входа — распространённая ошибка: приложение узнаёт, что «кто-то дал разрешение», но не может достоверно установить личность.

OIDC — надстройка над OAuth 2.0, добавляющая аутентификацию. Формат данных — JSON, транспорт — обычный HTTPS, что делает его удобным для мобильных приложений и API.

SAML — предшественник, основанный на XML. По-прежнему широко распространён в корпоративной среде, особенно там, где интеграции настраивались годами. Его слабые места: тяжеловесный формат, плохая совместимость с мобильными приложениями, отсутствие единообразной модели токенов.

Критерий	OIDC	SAML
Формат	JSON	XML
Мобильные приложения	Полноценная поддержка	Требует обходных решений
Модель токенов	ID, access, refresh	Подписанные assertion
Защита от повторного использования	Встроенные nonce и PKCE	Настраивается отдельно
Сложность интеграции	Низкая	Высокая

На практике протоколы сосуществуют: OIDC — для новых приложений, SAML — для унаследованных, которые нельзя переписать.

Практики безопасного внедрения

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

Держите время жизни access-токена коротким. Минуты, а не часы. Долгий доступ продлевается refresh-токеном, который можно отозвать.

Ограничивайте redirect URI строго. Никаких подстановочных символов. Свободный шаблон перенаправления — прямой путь к краже токена.

Запрашивайте минимальные права. Приложению для отображения профиля не нужен доступ к управлению пользователями.

Ротируйте клиентские секреты. Секрет приложения — такие же учётные данные, как пароль, и обращаться с ним нужно соответственно.

Журналируйте входы. Записи о выдаче токенов — основной материал при разборе инцидента. Аномалии по геолокации, устройству и частоте входов видны именно здесь.

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

Keydee выступает провайдером идентичности для ваших приложений и поддерживает Authorization Code Flow с PKCE как основной сценарий.

Что это даёт на практике:

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

Что стоит проверить перед переходом

Прежде чем подключать приложения, оцените готовность:

• умеют ли приложения корректно хранить и обновлять токены;
• везде ли используется HTTPS — без него ни один поток OIDC не безопасен;
• есть ли процесс отзыва сессии при увольнении или компрометации;
• как будут работать унаследованные системы, не понимающие OIDC.

Ответы на эти вопросы определяют порядок миграции: обычно начинают с новых приложений, а старые подключают по мере возможности.