Исследование конфигурации OpenID Connect: ключевые поля и их использование

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

Однако, правильная интеграция OIDC может быть сложной задачей, особенно для новичков. Хорошей отправной точкой часто является файл конфигурации OIDC, который обычно находится по адресу {authServerUrl}/.well-known/openid-configuration и содержит все необходимые детали для реализации OIDC-сервисов.

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

Анализ полей конфигурации OIDC#

Конфигурация OIDC представляет собой JSON-файл, подобный следующему:

Далее мы углубимся в некоторые из ключевых полей.

authorization_endpoint#

При интеграции OIDC-сервисов первый этап обычно включает в себя обработку запросов на вход пользователя в приложении. В этот процесс входит перенаправление пользователей на authorization_endpoint сервера авторизации. Этот конечный адрес сервера предназначен для отправки запросов на авторизацию и перенаправления пользователей на страницу входа для аутентификации.

При выполнении запроса на authorization_endpoint, он должен быть настроен с дополнительными параметрами запроса для каждой авторизации:

• response_type: Указывает тип возвращаемой авторизации. Это обычно включает "code" (для использования кода авторизации), "token" (для использования implicit flow) и "id_token token" или "code id_token" (для гибридного потока), которые можно найти в поле response_types_supported конфигурации OIDC.
• client_id: Уникальный идентификатор, присвоенный приложению сервером авторизации при регистрации приложения. Этот ID используется сервером авторизации для распознавания клиентского приложения, инициирующего запрос.
• scope: Определяет запрашиваемый доступ, указывая ресурсы или информацию о пользователе, к которым можно получить доступ. Общие области включают "openid" (обязательное), "profile" и "email" и другие. Вы можете найти поддерживаемые области в поле scopes_supported конфигурации OIDC; разные области должны быть разделены пробелами.
• redirect_uri: После завершения входа или авторизации сервер авторизации перенаправляет пользователя на URI, предоставленный приложением. Этот URI должен строго соответствовать URI, указанному при регистрации приложения.
• state: Случайная строка, используемая для защиты клиента от атак CSRF. Необходимо сохранять согласованность состояния между запросом на авторизацию и обратным вызовом для обеспечения безопасности.

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

После завершения запроса на authorization_endpoint и прохождения аутентификации, пользователи перенаправляются на указанный redirect_uri, который будет содержать очень важный параметр запроса — code. Этот код авторизации предоставляется сервером авторизации и является результатом того, что пользователь аутентифицировался и дал приложению разрешение на доступ к информации о себе на сервере авторизации.

token_endpoint#

token_endpoint — это конечная точка сервера, используемая сервером авторизации для обмена указанного выше кода авторизации на токены доступа и обновления. В authorization code flow OAuth 2.0 этот шаг является критическим, так как он включает преобразование полученного кода авторизации в реальные токены доступа, которые могут быть использованы приложением для доступа к защищенным ресурсам пользователя.

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

):

В этом коде мы сначала отправляем запрос на token_endpoint с использованием метода POST. Тип содержимого установлен на application/x-www-form-urlencoded, что требуется большинству серверов авторизации. Тело запроса включает следующие параметры:

• code: Код авторизации, полученный от сервера авторизации, который возвращается через redirectUri после завершения авторизации пользователя.
• redirect_uri: Тот же URI перенаправления, который был использован для получения кода авторизации, используется для проверки подлинности запроса.
• client_id: Идентификатор клиента приложения, используется для идентификации приложения, выполняющего запрос.
• client_secret: Секрет клиента приложения, используется для проверки подлинности приложения.
• grant_type: Указывает тип авторизации, здесь используется "authorization_code", что означает, что токен доступа получается через код авторизации.

Эта функция выполнена асинхронно и возвращает JSON-объект, содержащий токен доступа, который приложение может использовать для запроса данных пользователя или выполнения других операций.

userinfo_endpoint#

userinfo_endpoint — это конечная точка сервера, используемая сервером авторизации для получения детальной информации о аутентифицированных пользователях. После успешной авторизации пользователей и получения токенов доступа через token_endpoint, приложение может запросить эту конечную точку для получения информации профиля пользователя, такой как имя пользователя и адрес электронной почты. Конкретная получаемая информация зависит от scope, указанного пользователем в запросе на аутентификацию.

В этой функции мы сначала используем метод GET для запроса userinfo_endpoint, включая поле Authorization в заголовок запроса, состоящее из значений token_type и accessToken. Это стандартная операция, согласно спецификации OAuth 2.0, обеспечивающая безопасное получение информации о пользователе. Кроме того, объем информации о пользователе, доступной через токен доступа, полностью зависит от значений параметра scope, выбранных пользователем на этапе инициирования авторизации. Например, если используется область email, в ответе должен быть указан адрес электронной почты пользователя.

issuer & jwks_uri#

Игрок идентифицирует URL сервера авторизации, в то время как jwks_uri предоставляет URI для набора JSON Web Key Set (JWKS), который представляет собой набор открытых ключей, используемых для проверки подписей JWT. Проверка issuer и подписи JWT является основным шагом в обеспечении безопасности токенов, однако на практике процесс проверки обычно включает также проверку сроков действия токена, аудитории, области разрешений и других важных полей.

Следующий код в основном демонстрирует, как использовать issuer и jwks_uri вместе для проверки JWT:

scopes_supported & claims_supported#

Поля claims_supported и scopes_supported объявляют поддерживаемые сервером авторизации атрибуты пользователей (claims) и области доступа (scopes). Они помогают клиентам понять, какие атрибуты пользователей и области доступа поддерживаются сервером авторизации, что позволяет клиентам эффективно формировать запросы на авторизацию и разбирать ответы.

При создании запроса на авторизацию клиенты могут указать необходимую scope в соответствии с потребностями приложения. Scope определяет ресурсы и операции, которые клиент запрашивает для доступа, такие как openid, email, profile и другие.

Важно отметить, что конкретные доступные claims для каждого запроса на авторизацию варьируются в зависимости от значений областей действия, указанных при запуске запроса на аутентификацию. Например, область email предоставляет доступ к адресу электронной почты пользователя, в то время как область phone предоставляет доступ к номеру телефона. Поэтому клиенты должны тщательно выбирать соответствующую область действия, чтобы соответствовать потребностям приложения при составлении запроса на авторизацию, чтобы они могли получить необходимые атрибуты пользователя:

token_endpoint_auth_methods_supported

#

Поле

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

При аутентификации с использованием конечной точки token, общие методы аутентификации включают client_secret_post, client_secret_basic и client_secret_jwt.

• client_secret_post: Клиент использует свой идентификатор клиента и клиентский секрет для составления формы закодированного тела, которое отправляется как часть тела запроса. Мы уже видели пример этого метода в разделе token_endpoint выше.

• client_secret_basic: Клиент использует свой идентификатор клиента и клиентский секрет для составления базового заголовка аутентификации, который добавляется в заголовок запроса.

• client_secret_jwt: Клиент использует JWT (JSON Web Token) в качестве утверждения клиента для аутентификации. Этот JWT содержит идентификатор клиента и некоторую дополнительную метаинформацию и подписывается с использованием клиентского секрета. После получения запроса сервер авторизации проверяет подлинность клиента, проверяя подпись JWT.

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

Резюме#

Теперь мы рассмотрели ключевые поля в конфигурации OIDC, сосредоточив внимание на их назначении и применении. Понимание этих деталей улучшит ваше представление о OpenID Connect, позволяя вам более эффективно интегрировать и использовать его в своих проектах. Вооруженные этими знаниями, вы лучше подготовлены к использованию полного потенциала OIDC для более безопасных и эффективных решений аутентификации пользователей.

Logto — это сервис аутентификации, построенный на основе OIDC, который предлагает полный набор SDK на различных языках, а также многочисленные учебные пособия по интеграции, что позволяет вам бесшовно интегрировать логины OAuth / OIDC в свои приложения за считанные минуты. Если вы ищете надежный и простой в использовании сервис OIDC, попробуйте Logto уже сегодня!