5.4.3. Гибридный сценарий аутентификации

5.4.3.1. При использовании гибридного сценария некоторые токены возвращаются из конечной точки авторизации, другие - из конечной точки токена.

Гибридный сценарий состоит из следующих действий:

1 Клиент генерирует запрос аутентификации, содержащий желаемые параметры запроса.

2 Клиент отправляет запрос на сервер авторизации.

3 Сервер авторизации аутентифицирует конечного пользователя.

4 Сервер авторизации получает согласие/авторизацию конечного пользователя.

5 Сервер авторизации возвращает конечного пользователя на клиент с передачей кода авторизации и в зависимости от типа ответа - одного или нескольких дополнительных параметров.

6 Клиент запрашивает ответ на конечной точке токена, используя код авторизации.

7 Клиент получает ответ, содержащий ID токен и токен доступа.

8 Клиент проверяет ID токен и извлекает идентификатор субъекта конечного пользователя (значение параметра <sub>).

5.4.3.2. При использовании гибридного сценария действия сервера авторизации и клиента, связанные с формированием запроса аутентификации, его передачей, проверкой, а также аутентификацией пользователя и получением его согласия, в целом те же, что и в сценарии с кодом авторизации (см. подпункты 5.4.2.2 - 5.4.2.7). При этом параметр <response_type> запроса аутентификации должен иметь одно из следующих значений: "code id_token", либо "code token", либо "code id_token token".

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

В случае успешного ответа на запрос аутентификации все параметры ответа добавляются к компоненте фрагмента URI переадресации. При этом клиенту возвращаются значения следующих параметров:

- <access_token>: токен доступа; обязательный, если значение параметра <response_type> запроса аутентификации равно "code token" или "code id_token token";

- <token_type>: тип токена; обязательный, если значение параметра <response_type> запроса аутентификации равно "code token" или "code id_token token"; если присутствует, значением должен быть тип "Bearer";

- <id_token>: ID токен; обязательный, если значением <response_type> является "code id_token" или "code id_token token";

- <code>: (обязательный) код авторизации;

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

- <expires_in>: (опциональный) время жизни токена доступа в секундах с момента генерации ответа.

5.4.3.4. Формат ID токена в данном сценарии аналогичен подпункту 5.4.2.16 со следующими дополнениями:

- параметр <nonce> обязательный;

- добавлен обязательный параметр <at_hash>: хэш-значение токена доступа; вычисляется сервером авторизации и проверяется клиентом как Base64url кодирование левой половины хэш-кода октетов ASCII представления значения <access_token>; если токен доступа не запрашивается, значение параметра <at_hash> должно отсутствовать;

- добавлен обязательный параметр <c_hash>, значение которого вычисляется сервером авторизации и проверяется клиентом как Base64url кодирование левой половины значения хэш-функции октетов ASCII представления значения параметра <code>.

5.4.3.5. Клиент должен убедиться в правильности ответа аутентификации:

- следуя правилам 5.4.2.15;

- проверив целостность токена доступа (если значение параметра <response_type> запроса аутентификации равно "code token" или "code id_token token") путем сравнения значения Base64url кодирования левой половины хэш-кода полученного значения <access_token> с полученным значением параметра <at_hash>;

- проверив целостность кода авторизации (если значение параметра <response_type> запроса аутентификации равно "code id_token" или "code id_token token") путем сравнения значения Base64url кодирования левой половины хэш-кода полученного значения <code> с полученным значением параметра <c_hash>.

5.4.3.6. При использовании гибридного сценария запрос токена клиентом, проверка запроса токена, генерация токена доступа и ID токена на конечной точке токена, их проверка клиентом, а также реакция на ошибки выполняются в соответствии с аналогичными действиями в сценарии с генерацией кода авторизации (см. подпункты 5.4.2.11 - 5.4.2.15).

Если ID токен возвращается как из конечной точки авторизации, так и из конечной точки токена, что имеет место для одного из двух значений <response_type>: "code id_token" и "code id_token token", значения <iss> и <sub> должны быть идентичны в обоих ID токенах. Все значения параметров события аутентификации, присутствующие в любом из них, должны присутствовать в обоих ID токенах. Если какой-либо ID токен содержит параметр конечного пользователя, присутствующий в обоих ID токенах, он должен иметь одинаковые значения в обоих ID токенах. Сервер авторизации может вернуть меньшее количество параметров о конечном пользователе из конечной точки авторизации, например по соображениям конфиденциальности.

Примечание. Дополнительные сведения о гибридном сценарии аутентификации приведены в [11] (подраздел 3.3).