Утверждения OpenID Connect и токены ID

OpenID Connect (OIDC) добавляет уровень идентификации поверх OAuth 2.0. OAuth 2.0 отвечает за авторизацию (к чему может получить доступ это приложение?), а OIDC отвечает на вопрос об идентичности (кто пользователь?). OIDC реализуется добавлением области действия "openid" в запрос OAuth 2.0, после чего сервер авторизации возвращает токен ID вместе с токеном доступа.

Токен ID в OIDC представляет собой JSON Web Token (JWT), содержащий утверждения об аутентифицированном пользователе. JWT подписывается сервером авторизации с использованием его закрытого ключа (обычно RS256 или ES256), а доверяющая сторона (клиентское приложение) проверяет подпись с помощью опубликованных сервером авторизации открытых ключей (конечной точки JWKS).

Обязательные и часто используемые утверждения токена ID: "sub" (субъект, уникальный идентификатор пользователя), "iss" (издатель, URL сервера авторизации), "aud" (аудитория, идентификатор клиента), "exp" (метка времени Unix истечения срока действия), "iat" (метка времени Unix выпуска). Необязательные утверждения: "auth_time" (время прохождения аутентификации), "nonce" (защита от повторного воспроизведения), "at_hash" (хеш токена доступа), "acr" (класс контекста аутентификации), "amr" (использованные методы аутентификации).

Конечная точка OIDC UserInfo возвращает дополнительные утверждения об аутентифицированном пользователе при вызове с действительным токеном доступа. Клиенты запрашивают определенные наборы утверждений с помощью областей действия: "profile" (имя, изображение, региональные настройки), "email" (электронная почта, подтверждение электронной почты), "address" (адрес в отформатированном виде), "phone" (номер телефона, подтверждение номера телефона). Ответ UserInfo представляет собой объект JSON или JWT.

Проверка токена ID начинается с проверки подписи. Клиент получает JWKS сервера авторизации из конечной точки стандартного обнаружения, находит ключ, соответствующий параметру "kid" (идентификатор ключа) в заголовке JWT, и проверяет подпись JWT. Это доказывает, что токен выпущен легитимным сервером авторизации и не был изменен.

После проверки подписи клиент должен проверить следующее: "iss" должен в точности совпадать с ожидаемым URL сервера авторизации, включая схему и путь. "aud" должен содержать собственный идентификатор клиента client_id. "exp" должен указывать на будущее время, поэтому просроченные токены нужно отклонять. "iat" должен указывать на достаточно недавнее время. Все четыре проверки обязательны согласно спецификации OIDC.

Утверждение nonce предотвращает атаки с повторным воспроизведением токена ID. Клиент генерирует случайное значение nonce и включает его в запрос авторизации. Сервер авторизации помещает nonce в токен ID. Клиент проверяет, что nonce в токене ID совпадает со значением, которое он отправил. Это не позволяет злоумышленнику, перехватившему токен ID, повторно использовать его для аутентификации в другом сеансе.

Когда OIDC использует неявный поток (response_type=id_token), токен ID возвращается непосредственно во фрагменте URL. Клиент должен проверить at_hash (хеш токена доступа), чтобы связать токен доступа с токеном ID. Без проверки at_hash возможны атаки с подменой токена доступа. Это еще одна причина, по которой неявный поток объявлен устаревшим.

OIDC определяет стандартные соответствия между областями действия и утверждениями. Область действия "openid" обязательна и возвращает утверждение "sub". Область действия "profile" возвращает name, given_name, family_name, nickname, picture, website, locale, zoneinfo, updated_at. Область действия "email" возвращает email и email_verified. Запрос ненужных областей действия нарушает принцип минимального раскрытия данных и может привести к раскрытию конфиденциальных данных пользователя.

При реализации входа через несколько поставщиков OIDC (например, "Войти через Google" и "Войти через GitHub") возможны атаки с внедрением утверждений. Если злоумышленник создает учетную запись у поставщика B с адресом электронной почты жертвы, использующей поставщика A, он может получить доступ, если приложение сопоставляет учетные записи только по утверждению email. Всегда сопоставляйте учетные записи по паре (iss, sub), а не только по адресу электронной почты.

Гибридный поток OIDC (response_type=code id_token) возвращает с конечной точки авторизации и код авторизации, и токен ID. Токен ID позволяет немедленно проверить идентичность, а код обменивается на токены по обратному каналу. Такой поток используется, когда клиенту нужно сразу отобразить сведения о пользователе до завершения обмена токена по обратному каналу.

Какую комбинацию утверждений доверяющая сторона должна проверить в токене ID OIDC?

OIDC добавляет в потоки OAuth 2.0 подписанный токен ID в формате JWT. Проверяйте подпись (JWKS), iss (точное совпадение), aud (client_id), exp (срок действия не истек) и nonce (если он отправлялся). Конечная точка UserInfo предоставляет дополнительные утверждения через области действия. Для предотвращения внедрения утверждений сопоставляйте учетные записи по паре (iss, sub), никогда не используйте только адрес электронной почты. Неявный поток объявлен устаревшим; для OIDC используйте код авторизации с PKCE.