5.4.2.1. Сценарий протокола аутентификации OpenID Connect с генерацией кода авторизации использует код авторизации в качестве типа разрешения на доступ (grant). При этом выполняются следующие действия:

1 Клиент генерирует запрос аутентификации.

2 Клиент, используя агент пользователя (User Agent), отправляет запрос аутентификации на конечную точку авторизации сервера авторизации.

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

4 Сервер авторизации получает разрешение конечного пользователя на доступ клиента к защищенным ресурсам.

5 Сервер авторизации генерирует код авторизации и перенаправляет агент пользователя на конечную точку клиента, включая значение сгенерированного кода авторизации в состав параметров запроса на переадресацию.

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

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

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

5.4.2.2. В состав запроса аутентификации клиент может включать следующие параметры:

- <scope>: (обязательный) область действия; определяет свойства защищаемых данных конечного пользователя, к которым запрошен доступ; в случае использования протокола OpenID Connect параметр <scope> должен содержать строку "openid";

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

- "code": возвращает код авторизации; используется в сценарии аутентификации с генерацией кода авторизации;

- <client_id>: (обязательный) идентификатор клиента OAuth2.0, полученный при регистрации на сервере авторизации (см. подпункт 5.4.4.5);

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

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

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

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

- "none" - не требуется интерфейс пользователя,

- "login" - серверу авторизации рекомендуется запросить повторную аутентификацию,

- "consent" - серверу авторизации рекомендуется запросить у пользователя согласие на доступ к ресурсу,

- "select_account" - серверу авторизации рекомендуется запросить у пользователя выбор учетной записи;

- <max_age>: (опциональный) максимальный срок аутентификации. Определяет допустимое время в секундах, прошедшее с момента последней активной аутентификации конечного пользователя сервером авторизации. Если истекшее время больше этого значения, сервер авторизации должен пытаться активно повторно аутентифицировать конечного пользователя. Если в запросе аутентификации присутствует параметр <max_age>, возвращаемый ID токен должен включать значение параметра <auth_time>.

Примечание. Дополнительные сведения по параметрам запроса аутентификации приведены в RFC 6749 [10] (пункт 4.1.1) и в OIDC [11] (подпункт 3.1.2.1).

5.4.2.3. Серверы авторизации должны поддерживать на конечной точке авторизации методы HTTP GET и POST. Клиенты могут использовать методы HTTP GET или POST для отправки запроса аутентификации на сервер авторизации. При использовании метода HTTP GET параметры запроса сериализуются с использованием URI Query String Serialization (см. [11], подраздел 13.1). При использовании метода HTTP POST параметры запроса сериализуются с использованием сериализации форм (Form Serialization) (см. [11], подраздел 13.2).

5.4.2.4. Также параметры запроса аутентификации могут быть переданы в качестве параметров (claims) JSON объекта запроса - JWT токена. JWT токен должен быть подписан и может быть зашифрован. JWT токен передается в кодировании Base64url (см. [14], раздел 5) по значению через параметр <request> или по ссылке через параметр <request_uri>.

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

5.4.2.5. Сервер авторизации должен проверить полученный запрос следующим образом:

1 Проверить наличие обязательных параметров запроса и их соответствие спецификациям OAuth 2.0 и OIDC.

2 Убедиться, что параметр <scope> содержит значение области действия "openid".

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

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

5.4.2.6. Если запрос аутентификации действителен, сервер авторизации пытается аутентифицировать конечного пользователя или определяет, аутентифицирован ли конечный пользователь. Методы, используемые сервером авторизации для аутентификации конечного пользователя (например, имя пользователя и пароль, файлы cookie сеанса и т.д.), не регламентируются настоящим стандартом.

Сервер авторизации должен запрашивать аутентификацию конечного пользователя в следующих случаях:

- конечный пользователь еще не аутентифицирован;

- запрос аутентификации содержит параметр <prompt> со значением "login". В этом случае сервер авторизации должен повторно аутентифицировать конечного пользователя, даже если конечный пользователь уже аутентифицирован.

Сервер авторизации не должен взаимодействовать с конечным пользователем в следующем случае: запрос аутентификации содержит параметр <prompt> со значением "none". В этом случае сервер авторизации должен возвратить ошибку, если конечный пользователь еще не прошел аутентификацию или не может быть аутентифицирован в режиме без вывода сообщений.

При взаимодействии с конечным пользователем сервер авторизации должен использовать соответствующие меры против подделки межсайтовых запросов (CSRF) и перехвата кликов (Clickjacking).

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

- через интерактивный диалог с конечным пользователем, в ходе которого сервер авторизации отображает запрашиваемую клиентом область действия и запрашивает у конечного пользователя согласие на доступ;

- путем установления согласия с помощью условий обработки запроса;

- другими способами (например, с помощью предыдущего административного согласования).

5.4.2.8. После успешной аутентификации конечного пользователя и получения его разрешения на доступ клиента к защищенному ресурсу сервер авторизации генерирует код авторизации и передает его на конечную точку клиента, воспользовавшись адресом, который был ранее указан в параметре <redirect_uri> запроса аутентификации, с использованием формата "application/x-www-form-urlencoded". Параметры успешного ответа на запрос аутентификации:

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

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

5.4.2.9. В случае ошибки при проверке запроса аутентификации либо в процессе аутентификации конечного пользователя сервер авторизации отвечает клиенту с указанием информации об ошибке.

Параметры сообщения об ошибке:

- <error>: (обязательный) код ошибки;

- <error_description>: (опциональный) текстовое описание ошибки;

- <error_uri>: (опциональный) URI веб-страницы с дополнительной информацией об ошибке;

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

Возможные значения кода ошибки:

- "invalid_request": в запросе отсутствует обязательный параметр, или он содержит недопустимое значение параметра, или содержит параметр более одного раза, или имеет иные неправильные значения параметров;

- "unauthorized_client": клиент не авторизован для запроса кода авторизации с использованием данного метода;

- "access_denied": владелец ресурса или сервер авторизации отклонил запрос;

- "unsupported_response_type": сервер авторизации не поддерживает выдачу кода авторизации с использованием данного метода;

- "invalid_scope": запрошенная область действия недействительна, неизвестна или имеет неправильный формат;

- "server_error": сервер авторизации обнаружил непредвиденное состояние, которое не позволило ему выполнить запрос;

- "temporarily_unavailable": сервер авторизации в настоящее время не может обработать запрос из-за временной перегрузки или обслуживания сервера;

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

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

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

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

- "invalid_request_uri": попытка доступа по адресу <request_uri> в запросе авторизации возвращает ошибку или содержит неверные данные;

- "invalid_request_object": параметр <request> содержит недопустимый объект запроса;

- "request_not_supported": сервер авторизации не поддерживает использование параметра <request>;

- "request_uri_not_supported": сервер авторизации не поддерживает использование параметра <request_uri>;

- "registration_not_supported": сервер авторизации не поддерживает использование параметра <registration>.

5.4.2.10. Получив успешный ответ на запрос аутентификации, клиент проверяет его. Клиент должен игнорировать нераспознанные параметры ответа. Клиент должен проверить соответствие длин параметров установленным при разработке сервера авторизации ограничениям. Клиент должен проверить, совпадает ли значение параметра <state>, полученное в составе ответа, со значением параметра <state> в запросе аутентификации, переданным клиентом.

5.4.2.11. В случае успешной проверки ответа сервера авторизации клиент формирует и отправляет на адрес конечной точки токена запрос токена. Параметры запроса токена:

- <grant_type>: (обязательный) тип разрешения; в данном случае значением должна быть строка "authorization_code";

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

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

- <client_id>: (обязательный) идентификатор клиента, зарегистрированный сервером авторизации.

Примечание. Дополнительные сведения по запросу токена см. в [10] (пункт 4.1.3) и [11] (подпункт 3.1.3.1).

5.4.2.12. Сервер авторизации должен проверить запрос токена следующим образом:

- аутентифицировать клиента в соответствии с подразделом 5.5;

- убедиться, что код авторизации был выдан аутентифицированному клиенту;

- убедиться, что код авторизации действителен;

- убедиться, что код авторизации ранее не использовался;

- убедиться, что значение параметра <redirect_uri> совпадает со значением параметра <redirect_uri>, которое было включено в начальный запрос авторизации. Если значение параметра <redirect_uri> отсутствует при наличии только одного зарегистрированного значения <redirect_uri>, сервер авторизации может вернуть ошибку (так как клиент должен был включить параметр) или может работать без ошибки (так как OAuth 2.0 разрешает опускать этот параметр в таком случае);

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

- убедиться, что использованный код авторизации был выдан в ответ на запрос аутентификации OpenID Connect.

5.4.2.13. Коды авторизации должны быть кратковременными и одноразовыми. Если сервер авторизации регистрирует несколько попыток обмена одного и того же кода авторизации на токен доступа, серверу авторизации следует отозвать все токены доступа, уже предоставленные на основе скомпрометированного кода авторизации.

Примечание. Время действия кода авторизации определяется на этапе разработки сервера авторизации.

Сервер авторизации должен аутентифицировать клиента (см. подраздел 5.5) и гарантировать, что код авторизации был выдан клиенту, запросившему его.

5.4.2.14. Получив и успешно проверив запрос токена, сервер авторизации генерирует ID токен (см. подпункт 5.4.2.16), токен доступа (см. подпункт 5.4.2.18), а также, если необходимо, токен обновления (см. подпункт 5.4.2.19) и возвращает их клиенту по адресу <redirect_uri> в теле HTTP ответа с кодом состояния 200 (ОК). В ответе используется тип формата "application/json". Ответ должен включать следующие поля и значения заголовка HTTP ответа:

Cache-Control: no-store

Pragma: no-cache

Параметры JSON структуры ответа на запрос токена:

- <access_token>: (обязательный) токен доступа;

- <token_type>: (обязательный) тип токена, должен иметь значение "Bearer";

- <expires_in>: (рекомендуемый) время жизни токена в секундах;

- <refresh_token>: (опциональный) токен обновления;

- <scope>: (опциональный) область действия токена доступа;

- <id_token>: (обязательный) ID токен, связанный с текущей сессией доступа.

В случае ошибки проверки запроса токена сервер авторизации должен ответить сообщением об ошибке. Параметры и формат сообщения об ошибке приведены в подпункте 5.4.2.9. В теле HTTP ответа используется тип "application/json" с кодом HTTP ответа 400.

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

5.4.2.15. Клиент должен проверять правильность ответа на запрос токена следующим образом:

- клиент должен игнорировать нераспознанные параметры ответа;

- клиент должен прекратить проверку, если отсутствует значение хотя бы одного из обязательных параметров;

- клиент должен сверить длины параметров с установленными в системе;

- клиент должен проверить правильность ID токена согласно подпункту 5.4.2.17.

5.4.2.16. ID токен - это токен безопасности, который содержит параметры аутентификации конечного пользователя сервером авторизации. ID токен представляется в виде структуры JWT (см. подраздел 5.7).

ID токен включает следующие параметры:

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

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

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

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

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

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

- <nonce>: строковое значение; равно значению параметра <nonce>, в запросе аутентификации; серверу авторизации следует включать этот параметр, если значение параметра <nonce> присутствует в соответствующем запросе аутентификации;

- <azp>: (опциональный) идентификатор клиента стороны, для которого был выпущен ID токен.

ID токен должен быть подписан с использованием JWS (см. пункт 5.7.1). Он может быть подписан с использованием JWS и затем зашифрован с использованием JWE (см. пункт 5.7.2), как структура Nested JWT (см. подраздел 5.7). При этом в ID токене не должна использоваться строка "none" в качестве значения параметра <alg>.

5.4.2.17. Проверка ID токена клиентом должна выполняться следующим образом:

1 Если ID токен зашифрован, следует расшифровать его, используя ключи и алгоритмы, которые сервер авторизации должен был использовать для шифрования ID токена как JWE (см. 5.8.1 и 5.7.2).

2 Идентификатор эмитента (сервера авторизации), полученный при регистрации клиента, должен точно соответствовать значению параметра <iss> ID токена.

3 Клиент должен убедиться, что значение параметра <aud> содержит значение <client_id>, полученное клиентом от сервера авторизации при регистрации. ID токен должен быть отклонен, если <aud> не содержит значение <client_id> клиента.

4 Если ID токен содержит несколько компонент в составе параметра <aud>, клиент должен проверить наличие параметра <azp> и при его наличии проверить, что значение равно <client_id>.

5 Клиент должен проверить подпись структуры JWS ID токена, применяя алгоритм, указанный в параметре <alg>, используя ключ, предоставленный сервером авторизации. Если ID токен получен посредством прямого обмена данными между клиентом и конечной точкой токена, проверка сообщений протокола TLS от сервера может использоваться для проверки эмитента вместо проверки подписи токена.

6 Значение параметра <alg> должно быть значением по умолчанию или алгоритмом, зарегистрированным клиентом в значении параметра <id_token_signed_response_alg> во время регистрации.

7 Если в значении параметра <alg> указан алгоритм MAC, то в качестве ключа должны использоваться октеты UTF-8 представления <client_secret>, соответствующего <client_id> клиента.

8 Текущее время проверки должно быть раньше времени, указанного в значении параметра <exp>.

9 Для отзыва токенов, выпущенных слишком давно, может использоваться параметр <iat>, который ограничивает время, необходимое для хранения значений параметра <nonce>. Приемлемый диапазон определяется при разработке сервера авторизации.

10 Если в запросе аутентификации, отосланном клиентом в адрес сервера авторизации, указано значение параметра <nonce>, в структуре ID токена также должно присутствовать значение параметра <nonce>. Следует убедиться, что эти два значения совпадают.

11 Если запрашивалось значение параметра <auth_time> либо посредством специального запроса этого параметра, либо указанием параметра <max_age> в запросе аутентификации, клиенту следует проверить значение параметра <auth_time> на допустимость диапазону <max_age> и сделать запрос повторной аутентификации, если он определяет, что с момента последней аутентификации конечного пользователя прошло слишком много времени.

Примечание. Дополнительные сведения об использовании ID токена см. в разделе 2 [11].

5.4.2.18. Токен доступа (access token) - свидетельство, представляющее авторизацию, выданную клиенту сервером авторизации с одобрения владельца ресурса. Токен доступа содержит указание на конкретные области действия, к которым разрешен доступ, длительность доступа и другие параметры. Данная строка является случайной последовательностью символов и не несет смысловой нагрузки для клиента.

Рекомендуется время жизни токена ограничить однократным использованием или очень коротким временем жизни.

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

Примечание. Рекомендации по использованию токенов доступа см. в [11] (подраздел 16.18).

5.4.2.19. Токен обновления (refresh token) - это свидетельство, используемое для получения токенов доступа. Токен обновления выдается клиенту сервером авторизации и используется для получения нового токена доступа, когда текущий токен доступа становится недействительным или истекает его срок действия, или для получения дополнительных токенов доступа с идентичной или более узкой областью действия (токены доступа могут иметь более короткий срок службы и меньше разрешений на доступ, чем разрешено владельцем ресурса). Выдача токена обновления необязательна и выполняется по усмотрению сервера авторизации. Если сервер авторизации выдает токен обновления, он включается в ответ при выдаче токена доступа. Данная функциональность не входит в область действия настоящего документа и определяется на этапе разработки сервера авторизации, исходя из его прикладных целей и задач.

Для постоянного доступа к конечной точке UserInfo или другим защищенным ресурсам используется токен обновления. Клиент может обменять токен обновления в конечной точке токена на новый кратковременный токен доступа, который можно использовать для доступа к ресурсу.

Решение о необходимости выдачи токена обновления принимается на этапе разработки сервера авторизации.

5.4.2.20. Клиент может получить информацию о конечном пользователе, либо извлекая ее из параметров ID токена, либо с помощью запроса к конечной точке UserInfo сервера авторизации.

Чтобы получить значение параметра информации о конечном пользователе, клиент отправляет запрос конечной точке UserInfo, используя токен доступа, полученный при аутентификации на сервере авторизации. Значения параметров в ответ возвращаются в виде JSON объекта, который содержит коллекцию пар "имя и значение параметра". Конечная точка UserInfo должна принимать токены доступа на предъявителя ("Bearer").

Конечная точка UserInfo должна поддерживать использование методов HTTP GET и HTTP POST. Взаимодействие между клиентом и сервером авторизации при обращении клиента на точку UserInfo должно быть защищено протоколом TLS.

Примечание. Сведения об алгоритмах работы в конечной точке UserInfo приведены в [11] (подраздел 5.3).