OpenID Connect: идентичность поверх OAuth 2.0

Авторизация — не аутентификация

OAuth 2.0 отвечает на вопрос «уполномочено ли это приложение получить доступ к тому ресурсу от имени пользователя?». Это протокол авторизации, и он намеренно не говорит ничего стандартного о том, кто такой пользователь. Тем не менее приложения пытались использовать его повторно для входа, способами несовместимыми и порой небезопасными. OpenID Connect (OIDC) — стандарт, который это исправляет: тонкий слой идентичности поверх OAuth 2.0, добавляющий аутентификацию, не отбрасывая ничего из того, что OAuth уже делает.

ID-токен

Определяющее дополнение — ID-токен, и это JWT. Тогда как токен доступа OAuth предназначен для API и часто непрозрачен для клиента, ID-токен предназначен для клиента и несёт стандартные утверждения об аутентифицированном пользователе:

• iss (издатель) и aud (аудитория, клиент, для которого он выпущен)
• sub (стабильный уникальный идентификатор пользователя)
• exp и iat (срок действия и время выпуска)
• nonce (связывает токен с конкретным запросом входа и побеждает повтор)
• утверждения профиля, такие как name, email и picture, когда эти области предоставлены

Поскольку это JWT, клиент проверяет подпись ID-токена и валидирует эти утверждения точно так, как описано для любого JWT. Применяются те же проверки фиксации алгоритма и aud/iss/exp.

Как протекает вход

OIDC повторно использует механизм OAuth. Рекомендуемый поток — поток кода авторизации с PKCE:

1. Приложение отправляет пользователя к конечной точке авторизации провайдера, запрашивая область openid (плюс profile, email и так далее) и включая PKCE code_challenge.
2. Пользователь аутентифицируется и даёт согласие у провайдера.
3. Приложение получает одноразовый код и обменивает его (доказывая владение PKCE code_verifier) на ID-токен и токен доступа.
4. Приложение проверяет ID-токен, чтобы установить, кто такой пользователь, и использует токен доступа для вызова API от его имени.

Две конечные точки дополняют картину: конечная точка userinfo возвращает утверждения профиля для действительного токена доступа, а документ обнаружения по адресу /.well-known/openid-configuration объявляет конечные точки провайдера и его адрес JWKS, чтобы клиент мог найти ключи для проверки ID-токенов и автоматически следить за ротацией ключей.

Почему это важно

OIDC — это то, на чём на самом деле работает большинство кнопок «Войти через ...». Разделение двух токенов — ключевое понимание: ID-токен доказывает идентичность клиенту, токен доступа авторизует вызовы API, и они не взаимозаменяемы. В сочетании с потоком кода и PKCE это современный, основанный на стандартах способ федеративного входа.

Инструмент PKCE генерирует и проверяет code_verifier и code_challenge потока, а инструмент JWT декодирует и проверяет ID-токен, оба целиком в вашем браузере, без отправки чего-либо.