7.2.2. ID токен в качестве отделенной подписи

Кроме того, если используется значение <response_type> = "code id_token", сервер авторизации:

1. Должен поддерживать OpenID Connect в объеме методических рекомендаций [5].

2. Должен поддерживать подписанные ID токены.

3. Должен поддерживать подписанные и зашифрованные ID токены.

4. Должен возвращать ID токен в качестве отделенной подписи (detached signature) к ответу авторизации.

Примечание. ID токен не только подтверждает идентификацию владельца ресурса (субъекта), он также идентифицирует сервер авторизации (содержит идентификатор эмитента). В случае если ID токен включает идентификатор субъекта, он действует как отделенная подпись (detached signature) источника данных к ответу авторизации. Таким образом, ID токен также защищает ответ авторизации путем включения в ID токен хэш-кода незащищенных параметров ответа <code> и <state>.

5. Если клиент предоставил значение <state>, для его защиты должен включать в ID токен хэш-код состояния <s_hash>. <s_hash> может быть опущен в ID токене, возвращаемом с конечной точки токена, если <s_hash> присутствует в ID токене, возвращаемом с конечной точки авторизации.

6. Не должен возвращать конфиденциальные персональные данные в ID токене в ответе авторизации.

Примечание. Сервер авторизации может вернуть из конечной точки авторизации больше параметров в составе ID токена, чем в ответе авторизации, согласно синтаксису OAuth 2.0.