OpenID Connect

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

История и предпосылки создания

До появления OIDC основным протоколом для децентрализованной аутентификации был OpenID 2.0, который, несмотря на свою популярность, имел ряд недостатков: сложность реализации, отсутствие встроенной поддержки JSON и REST-архитектуры, а также проблемы с безопасностью. Параллельно развивался протокол OAuth 2.0, который стал стандартом для авторизации, но не предоставлял стандартного способа аутентификации.

В 2012 году сообщество разработчиков осознало необходимость создания единого протокола, который бы сочетал простоту OAuth 2.0 с возможностями аутентификации OpenID. В результате был разработан OpenID Connect, который использует OAuth 2.0 в качестве транспортного уровня, добавляя к нему специфичные для аутентификации механизмы. Первая финальная версия спецификации (1.0) была опубликована в феврале 2014 года. С тех пор OIDC стал основой для многих современных систем единого входа (Single Sign-On, SSO) и федеративных систем управления идентификацией.

Архитектура и основные концепции

Протокол OIDC основан на модели «клиент-сервер», где участвуют три основные стороны:

• Пользователь (End-User) — человек, который хочет получить доступ к защищённому ресурсу.
• Поставщик удостоверений (Identity Provider, IdP) — сервер, который хранит учётные записи пользователей и выдает токены аутентификации. Примеры IdP: Google, Яндекс, Microsoft, Keycloak, Auth0.
• Стороннее приложение (Relying Party, RP) — веб-сайт или приложение, которое хочет аутентифицировать пользователя через IdP.

Ключевым нововведением OIDC является ID Token — токен в формате JSON Web Token (JWT), который содержит утверждения (claims) о пользователе. ID Token включает обязательные поля: идентификатор пользователя (sub), идентификатор поставщика удостоверений (iss), время выдачи (iat) и время истечения (exp). Дополнительно могут передаваться такие данные, как имя пользователя, адрес электронной почты, дата рождения и т.д.

Потоки аутентификации (Flows)

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

• Authorization Code Flow — наиболее безопасный и рекомендуемый поток для веб-приложений. Клиент сначала получает временный код авторизации, который затем обменивает на ID Token и Access Token на серверной стороне. Этот поток позволяет избежать передачи токенов через браузер пользователя.
• Implicit Flow — упрощённый поток, при котором токены возвращаются непосредственно в браузере через URL-фрагмент. Используется в одностраничных приложениях (SPA), но считается менее безопасным, чем Authorization Code Flow. В современных рекомендациях его использование не рекомендуется.
• Hybrid Flow — комбинированный поток, при котором часть токенов (например, ID Token) возвращаются через браузер, а часть (Access Token) — через серверную сторону. Используется в сложных сценариях, где требуется высокая производительность.
• Client Credentials Flow — поток для машинной аутентификации (сервер-сервер), где клиент аутентифицируется без участия пользователя, используя свой собственный секретный ключ. Этот поток не возвращает ID Token, так как не связан с конкретным пользователем.

Структура токенов и данные

Основные типы токенов в OIDC:

• ID Token — JWT, содержащий информацию о пользователе и его аутентификации. Он подписан цифровой подписью (RS256, ES256 или HS256) для обеспечения целостности и подлинности.
• Access Token — токен, который используется для доступа к защищённым ресурсам (например, к API). Его формат и содержимое не стандартизированы OIDC (обычно это JWT или opaque token).
• Refresh Token — долгоживущий токен, который позволяет получить новый Access Token без повторной аутентификации пользователя.

Стандартные утверждения (Claims)

Спецификация OIDC определяет набор стандартных утверждений, которые могут быть включены в ID Token или получены через UserInfo Endpoint:

• sub — уникальный идентификатор пользователя (обязательное поле).
• name — полное имя пользователя.
• given_name — имя.
• family_name — фамилия.
• email — адрес электронной почты.
• email_verified — флаг, подтверждающий, что email был проверен.
• phone_number — номер телефона.
• picture — URL аватара пользователя.

Применение и значение

OpenID Connect широко используется в современных веб- и мобильных приложениях для реализации единого входа (SSO). Это позволяет пользователям входить на множество сайтов с помощью одной учётной записи (например, через Google, Яндекс, VK или Apple). Основные области применения:

• Корпоративные системы — OIDC используется для аутентификации сотрудников в корпоративных приложениях (например, Microsoft Entra ID, Okta, Keycloak).
• Облачные сервисы — многие облачные платформы (Google Cloud, Microsoft Azure, Amazon Web Services) используют OIDC для управления доступом к API.
• Мобильные приложения — OIDC обеспечивает безопасную аутентификацию в мобильных приложениях через Authorization Code Flow с использованием PKCE (Proof Key for Code Exchange).
• Государственные и банковские системы — в России протокол OIDC используется в единой биометрической системе (ЕБС) и в некоторых банковских приложениях для аутентификации клиентов.

Безопасность и критика

OpenID Connect считается одним из самых безопасных протоколов аутентификации, однако его реализация требует соблюдения ряда мер предосторожности:

• Защита от CSRF — необходимо использовать параметр state для предотвращения межсайтовой подделки запросов.
• Защита от атак на перенаправление — клиент должен проверять, что redirect URI совпадает с зарегистрированным.
• Использование PKCE — для мобильных и SPA-приложений рекомендуется использовать PKCE, чтобы предотвратить перехват кода авторизации.
• Проверка подписи ID Token — клиент должен проверять цифровую подпись ID Token, чтобы убедиться, что он был выдан доверенным IdP.

Критика OIDC связана с его сложностью по сравнению с более простыми решениями, такими как SAML или токены на основе паролей. Также отмечается, что протокол требует значительных вычислительных ресурсов для проверки подписей JWT, что может быть проблемой для высоконагруженных систем.

Интересные факты

• OpenID Connect поддерживает механизм Discovery (OpenID Connect Discovery), который позволяет клиенту автоматически получить конфигурацию IdP по известному URL (например, /.well-known/openid-configuration).
• Протокол поддерживает Dynamic Client Registration — возможность автоматической регистрации новых клиентов без ручного вмешательства администратора.
• В России OIDC используется в единой системе идентификации и аутентификации (ЕСИА) для портала «Госуслуги», хотя основным протоколом там является SAML.
• OpenID Connect является основой для стандарта FAPI (Financial-grade API), который используется в банковской сфере для обеспечения высокого уровня безопасности.

Источники

• OpenID Foundation. OpenID Connect Core 1.0 Specification. 2014.
• OpenID Foundation. OpenID Connect Discovery 1.0 Specification. 2014.
• RFC 6749 — The OAuth 2.0 Authorization Framework.
• RFC 7519 — JSON Web Token (JWT).
• RFC 7636 — Proof Key for Code Exchange (PKCE).
• Документация к Keycloak, Auth0, Microsoft Entra ID.