OpenID Connect (OIDC)

OpenID Connect — это тонкий уровень идентификации, построенный поверх OAuth 2.0. OAuth отвечает на вопрос что может делать это приложение, а OIDC — на вопрос кто этот пользователь.

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

До появления OIDC разработчики использовали токены доступа OAuth не по назначению для входа в систему, что приводило к ошибкам с полномочиями и подмене личности.

Главный артефакт OIDC — это ID-токен, подписанный JWT, описывающий событие аутентификации.

• Он содержит утверждения о том, кто вошел в систему и когда это произошло.
• Он предназначен для обработки клиентом, а не сервером ресурсов.

Никогда не отправляйте ID-токен в API как учетные данные доступа и никогда не принимайте его без проверки подписи и утверждений.

Проверка ID-токена означает проверку конкретных утверждений, а не только подписи.

• Издатель iss должен соответствовать ожидаемому IdP.
• Аудитория aud должна содержать ваш client_id.
• exp / iat: срок действия токена не должен истечь, а сам токен должен быть выпущен недавно.
• sub: стабильный уникальный идентификатор пользователя.
• nonce должен совпадать со значением, отправленным вашим клиентом.

OIDC повторно использует поток кода авторизации, добавляя область доступа openid и значение nonce.

• Клиент запрашивает область доступа openid (а также необязательные profile и email).
• Конечная точка токенов возвращает ID-токен вместе с токеном доступа.
• nonce связывает ID-токен с исходным запросом и предотвращает повторное использование.

Поставщики OIDC публикуют ключи подписи в конечной точке JWKS, которую можно обнаружить через документ общедоступной конфигурации.

• Получите ключи из jwks_uri и сопоставьте их с заголовком kid токена.
• Проверьте подпись с помощью указанного асимметричного алгоритма (RS256, ES256).

Отклоняйте алгоритм none и никогда не доверяйте значению алгоритма, переданному только самим токеном.

Для ID-токенов nonce выполняет ту же роль, что и state для перенаправления: это одноразовое значение, связывающее ответ с запросом.

• Клиент создает случайное значение nonce и сохраняет его в сеансе.
• IdP возвращает его внутри ID-токена.
• Получив токен, клиент проверяет, что nonce совпадает и еще не использовался.

Это блокирует повторное использование токена и внедрение токена, выпущенного для другого сеанса.

Для получения дополнительных данных профиля помимо ID-токена OIDC определяет конечную точку UserInfo.

• Клиент обращается к ней с помощью токена доступа, а не ID-токена.
• Она возвращает такие утверждения, как имя, адрес электронной почты и изображение, для аутентифицированного субъекта.

Всегда сопоставляйте возвращенный sub с sub из ID-токена, чтобы предотвратить подмену утверждений.

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

• Документ /.well-known/openid-configuration содержит список конечных точек, поддерживаемых областей доступа и алгоритмов.
• Закрепляйте или проверяйте издателя; не переходите без проверки к данным обнаружения с узла, контролируемого атакующим.

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

Завершение сеансов в федерации приложений регулируется спецификациями выхода OIDC.

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

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

Ошибки идентификации часто возникают из-за пропуска этапов проверки.

• Прием токенов без проверки aud (токен предназначен для другого клиента).
• Игнорирование iss, позволяющее подменить IdP.
• Отсутствие проверки подписи или принятие alg: none.
• Путаница между ID-токенами и токенами доступа.
• Отсутствие проверки nonce, позволяющее повторное воспроизведение.

Если ваша цель — вход в систему, используйте OIDC, а не обычный OAuth.

• Токены доступа OAuth непрозрачны для клиента и ничего не доказывают об идентичности пользователя.
• Токен доступа может быть действительным для другого пользователя или приложения; его использование для входа может привести к подмене личности.
• ID-токены OIDC являются утверждениями идентичности, явно привязанными к аудитории.

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

Выберите наиболее важный этап проверки для доверяющей стороны, обрабатывающей ID-токен.

Основные выводы:

• OIDC добавляет уровень идентификации поверх OAuth 2.0; ID-токен — это подписанный JWT, подтверждающий прохождение аутентификации.
• Всегда проверяйте iss, aud, exp, подпись (через JWKS) и nonce.
• ID-токены предназначены для клиента, а токены доступа — для API; никогда не меняйте их роли местами.
• Используйте nonce для защиты от повторного воспроизведения, а state — для защиты от CSRF.
• Используйте OIDC, а не обычный OAuth, когда требуется аутентифицировать пользователей.