Как работают OpenID Connect и OAuth 2.0

Короткий ответ

OAuth 2.0 описывает получение ограниченного доступа к ресурсу. OpenID Connect, или OIDC, добавляет к нему стандартный способ подтвердить личность пользователя. Они работают вместе: приложение может получить результат входа и токен для обращения к API — программному интерфейсу другого сервиса.

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

Какие задачи решают OAuth 2.0 и OpenID Connect

OAuth 2.0 даёт приложению доступ к ресурсу

Рассмотрим условный пример: сервису планирования нужно прочитать события из календаря сотрудника. Сотрудник разрешает доступ у поставщика календаря, а сервис получает токен с ограниченными полномочиями. Передавать сервису пароль от календаря не требуется.

Токен предъявляют API календаря. Сервер проверяет его и решает, можно ли выполнить запрос. Разрешение читать события само по себе не означает разрешения удалять их. Запрашиваемую область доступа называют scope; конкретные значения определяет API.

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

OpenID Connect сообщает приложению, кто вошёл

Для создания пользовательского сеанса приложению нужен проверяемый результат аутентификации — подтверждения личности. OpenID Connect добавляет ID token: токен с идентификатором пользователя и сведениями о входе. Приложение проверяет его и находит соответствующую локальную учётную запись.

OIDC использует механизмы OAuth 2.0, поэтому выбирать между ними как между двумя независимыми способами входа не нужно. В одном обмене приложение может получить ID token для входа и access token для API. Связь протоколов определена в OpenID Connect Core ↗.

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

Как читать обмен

Такой обмен называется Authorization Code Flow — получением токенов через код авторизации. Механизм PKCE описан в RFC 7636 ↗, а актуальные рекомендации по защите OAuth 2.0 — в RFC 9700 ↗. Проверки протокола лучше поручать поддерживаемой библиотеке, сохраняя в коде приложения собственные правила допуска и работы с данными.

Зачем нужны разные токены

У токенов различаются получатель и назначение. Это важно даже тогда, когда внешне они похожи.

Сеанс приложения — отдельный механизм. После проверки входа веб-приложение может узнавать браузер по cookie своего сеанса. В описанной серверной схеме браузеру не требуется получать access token или refresh token для каждого открытия страницы.

JSON Web Token (JWT) — формат токена с набором полей, например идентификатором пользователя, издателем и сроком действия. ID token имеет формат JWT; access token может иметь другой формат. Формат описан в RFC 7519 ↗.

Прочитать поля JWT ещё не значит проверить его подлинность. Для подписанного токена нужна проверка подписи, а также издателя, назначения и срока действия. Подпись защищает от незаметного изменения, но сама по себе не скрывает содержимое: для этого нужно шифрование. Назначение ID token не позволяет автоматически использовать его вместо access token.

Как связаны единый вход и права внутри приложения

SSO позволяет использовать общий вход в нескольких системах

SSO, или Single Sign-On, — единый вход. Если несколько приложений доверяют одному поставщику идентификации, он может использовать уже открытый сеанс пользователя при переходе в следующее приложение. Повторный ввод пароля может не понадобиться; дополнительное подтверждение зависит от политики и ситуации.

Каждое приложение при этом получает собственный результат входа и отдельно управляет своим сеансом. Корпоративный каталог, например Active Directory, может служить источником учётных записей. LDAP — протокол обращения к таким каталогам, а Keycloak — сервер, который предоставляет приложениям OIDC и другие механизмы входа. Подготовку этой связки разобрали в Практике внедрения единого входа.

Права на данные определяются правилами приложения

Корпоративный вход может подтвердить личность сотрудника и передать сведения о группах. Затем приложение решает, разрешён ли ему вход, какую роль назначить и какие объекты показать. Например, право открыть систему не означает права читать документы другого подразделения.

Полученные группы и области доступа нужно сопоставить с серверными правилами. Как проверить доступ к чужим объектам, административным операциям и отдельным полям, описано в Практике проверки авторизации API. Остальные области риска рассматривает обзор проверки безопасности API.

Выход и отзыв доступа охватывают несколько состояний

Одновременно могут существовать сеанс у поставщика идентификации, сеанс приложения и выданные токены. Завершение одного состояния не доказывает прекращения остальных. В OIDC есть механизм запроса выхода у поставщика идентификации ↗; завершение сеансов других приложений требует поддержки и настройки соответствующих механизмов.

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

Как мы подключили внутреннюю систему к единому входу

Во внутренней рабочей системе RB Tech учётные записи уже были связаны с правами, данными и историей операций. Мы подключили корпоративный вход через Keycloak по OpenID Connect, сохранив эти связи.

Существующие учётные записи явно связали с идентификаторами пользователей у поставщика идентификации. Допуск к приложению ограничили корпоративной группой. Само наличие учётной записи в каталоге не создавало пользователя приложения автоматически и не давало ему бизнес-права.

При проверке интеграции подтвердили обмен OIDC, вход и выход для связанных учётных записей и отказ пользователю без допуска. Локальные идентификаторы и модель прав сохранились. Эти проверки относились к интеграции и допуску; многофакторная аутентификация (MFA) в них не проверялась.

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

Что это даёт бизнесу

Что дальше

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

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