5.4.4. Регистрация сервера авторизации (Discovery) и динамическая регистрация клиента

5.4.4.1. Прежде чем запустить сервис аутентификации и авторизации клиентов, сервер авторизации должен опубликовать свои метаданные, описывающие его адрес и параметры доступа в ходе процедуры OpenID Connect Discovery.

5.4.4.2. Настоящий стандарт не регламентирует способ получения адреса сервера авторизации. Этот адрес может предоставляться клиенту, например указанием его в документации на систему. Сервер авторизации может также запускать сервис, поддерживающий технологию WebFinger [25].

5.4.4.3. Клиент может, используя HTTP GET запрос по адресу сервера авторизации, получить конфигурацию сервера авторизации (документ Discovery), в которой в JSON формате перечислены метаданные сервера авторизации. В частности, в конфигурации перечислены значения таких параметров:

- <issuer>: (обязательный) https URL адрес, являющийся идентификатором эмитента (Issuer Identifier); далее это значение должно быть указано в качестве параметра <iss> в ID токенах; получив ответ, клиент должен проверить совпадение значения параметра <issuer> с адресом сервера авторизации, на который он делал запрос;

- <authorization_endpoint>: (обязательный) URI конечной точки авторизации (см. подпункты 5.4.2.2 - 5.4.2.9); может включать в себя компоненту запроса в формате "application/x-www-form-urlen-coded"; не должен включать компоненту фрагмента;

- <token_endpoint>: (обязательный кроме неявного сценария) URI конечной точки токена (см. подпункты 5.4.2.10 - 5.4.2.14); может включать в себя компоненту запроса в формате "application/x-www-form-urlencoded"; не должен включать компоненту фрагмента;

- <userinfo_endpoint>: (рекомендуемый) URI конечной точки UserInfo, предназначенный для запроса информации об аутентифицированном конечном пользователе (см. подпункт 5.4.2.20);

- <registration_endpoint>: (рекомендуемый) URI конечной точки динамической регистрации клиентов сервера авторизации (см. подпункт 5.4.4.5);

- <jwks_uri>: (обязательный) URL документа Key Set (см. подпункт 5.7.3.3) сервера авторизации, где публикуются его ключи в формате JWK; публикуемые сертификаты должны передаваться доверенным образом;

- <grant_types_supported>: (опциональный) перечень поддерживаемых сервером авторизации типов разрешений на доступ (grants); сервера авторизации OIDC должны поддерживать значения "authorization_code" и "implicit"; по умолчанию используется значение ["authorization_code", "implicit"];

- <scopes_supported>: (рекомендуемый) JSON массив значений параметра <scope>, которые поддерживает сервер авторизации;

- <response_types_supported>: (обязательный) JSON массив с перечнем поддерживаемых значений параметра <response_type>; сервера авторизации OIDC должны поддерживать значения "code", "id_token" и "token id_token";

- <response_modes_supported>: (опциональный) JSON массив с перечнем поддерживаемых значений параметра <response_mode>; по умолчанию ["query", "fragment"]; также в подразделе 8.3 приведен перечень значений <response_mode>, связанный с использованием технологии JARM;

- <claims_supported>: (рекомендуемый) JSON массив, содержащий список имен параметров, значения которых сервер авторизации может предоставить клиенту;

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

В подразделе 8.3 приведен перечень дополнительных метаданных сервера авторизации, связанных с использованием технологии JARM.

Адреса всех перечисленных выше конечных точек сервера авторизации должны быть разными.

Примечание. Дополнительные сведения о протоколе Discovery представлены в документах [26] и RFC 8414 [27].

5.4.4.4. Передача сообщений Discovery, в том числе и сообщений сервиса WebFinger, между клиентом и сервером авторизации должна быть защищена с помощью протокола TLS с обеспечением конфиденциальности и целостности. При этом должна выполняться аутентификация источника информации Discovery.

5.4.4.5. Процедура динамической регистрации клиента выполняется после того, как выполнена регистрация сервера авторизации, описанная выше.

Для регистрации клиент посылает HTTP POST запрос серверу авторизации на конечную точку регистрации клиентов (параметр <registration_endpoint> документа Discovery, см. подпункт 5.4.4.1) с типом содержимого "application/json", в котором указываются следующие метаданные клиента:

- <redirect_uris>: (обязательный) перечень поддерживаемых адресов переадресации клиента; одно из этих зарегистрированных значений URI переадресации должно точно соответствовать значению параметра <redirect_uri>, используемому в каждом запросе авторизации;

- <response_types>: (опциональный) JSON массив, содержащий перечень поддерживаемых клиентом типов ответа (см. подпункт 5.4.2.2); по умолчанию - значение "code";

- <grant_types>: (опциональный) JSON массив, содержащий перечень поддерживаемых клиентом типов разрешений на доступ (grants) из перечня: "authorization_code", "implicit", "refresh_token"; по умолчанию используется значение "authorization_code";

- <application_type>: (опциональный) тип клиента ("native" или "web");

- <contacts>: (опциональный) массив адресов электронной почты лиц, ответственных за этого клиента;

- <client_name>: (опциональный) имя клиента; оно будет показано конечному пользователю при запросе авторизации;

- <logo_uri>: (опциональный) URL ссылка на логотип клиентского приложения; если присутствует, сервер должен отображать это изображение конечному пользователю во время запроса авторизации;

- <client_uri>: (опциональный) URL домашней страницы клиента; если присутствует, сервер должен отображать этот URL-адрес конечному пользователю;

- <policy_uri>: (опциональный) URL-адрес, который клиент предоставляет конечному пользователю с информацией о том, как будут использоваться данные его профиля; если присутствует, сервер авторизации должен показать этот URL-адрес конечному пользователю;

- <tos_uri>: (опциональный) URL-адрес, который клиент предоставляет конечному пользователю для ознакомления с условиями обслуживания клиента; если присутствует, сервер авторизации должен показать этот URL-адрес конечному пользователю;

- <jwks_uri>: (опциональный) URI документа JWK Set (см. подпункт 5.7.3.3), содержащего ключи клиента в формате JWK; публикуемые сертификаты должны передаваться доверенным образом;

- <jwks>: (опциональный) документ JWK Set, передаваемый по значению; параметры <jwks_uri> и <jwks> не должны одновременно присутствовать в метаданных клиента; сертификаты открытых ключей должны передаваться доверенным образом;

- <default_max_age>: (опциональный) максимальный возраст аутентификации по умолчанию; указывает, что конечный пользователь должен быть повторно аутентифицирован, если с момента его аутентификации прошло более чем указанное количество секунд;

- <require_auth_time>: (опциональный) логическое значение, указывающее, требуется ли указывать параметр <auth_time> в ID токене; значением по умолчанию является "false";

- <token_endpoint_auth_method>: (опциональный) поддерживаемый метод аутентификации клиента на конечной точке токена; возможные варианты: "client_secret_post", "client_secret_ basic","client_secret_jwt","private_key_jwt", "tls_client_auth", "self_signed_tls_client_auth" и "none" (см. подраздел 5.5).

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

В случае если все запрошенные значения параметров клиента корректны, сервер авторизации должен, используя код HTTP 201, возвратить клиенту JSON документ с типом содержимого "application/json" со следующей информацией:

- <client_id>: (обязательный) уникальный идентификатор клиента, который далее будет использоваться клиентом в протоколах OIDC;

- <client_secret>: (опциональный) конфиденциальная информация, которая возвращается конфиденциальным клиентам и используется для аутентификации клиента сервером авторизации, а также для защиты взаимодействия клиента и сервера авторизации; значение этого параметра обязательно при использовании механизма аутентификации клиента <client_secret_jwt>;

- <client_id_issued_at>: (опциональный) время выдачи идентификатора клиента; значение представляет собой число, представляющее количество секунд от 1970-01-01T0:0:0Z UTC до текущего момента;

- <client_secret_expires_at>: (обязательный, если присутствует <client_secret>) время окончания действия <client_secret> или 0, если он не устаревает никогда; значение представляет собой число, представляющее количество секунд от 1970-01-01T0:0:0Z UTC до текущего момента.

Кроме того, сервер авторизации возвращает клиенту в составе ответа метаданные клиента, принятые сервером в запросе регистрации.

Должна быть обеспечена конфиденциальность передачи значения параметра <client_secret>. Механизм защиты должен быть определен на этапе разработки сервера авторизации.

5.4.4.7. При ошибке обработки запроса регистрации (см. подпункт 5.4.4.6) сервер авторизации не выполняет регистрацию клиента, а конечная точка регистрации возвращает клиенту код состояния HTTP 400, включая JSON объект, описывающий ошибку в теле ответа.

JSON объект, описывающий ошибку, содержит два обязательных параметра <error> и <error_description> в формате подпункта 5.4.2.9. Коды ошибки:

- "invalid_redirect_uri": значение одного или нескольких значений массива <redirect_uris> недопустимо;

- "invalid_client_metadata": значение одного из полей метаданных клиента недопустимо, и сервер отклонил этот запрос.

Примечание. Дополнительные сведения о динамической регистрации клиента приведены в документах [28] и [29].

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