RFC 6749 The OAuth 2.0 Authorization Framework | Энциклопедия сетевых протоколов

Internet Engineering Task Force (IETF)                     D. Hardt, Ed.
Request for Comments: 6749                                     Microsoft
Obsoletes: 5849                                             October 2012
Category: Standards Track
ISSN: 2070-1721

The OAuth 2.0 Authorization Framework

Модель предоставления полномочий OAuth 2.0

PDF

Аннотация

Модель предоставления полномочий (авторизации) OAuth 2.0 позволяет сторонним приложениям получать ограниченный доступ к услугам HTTP от имени владельца ресурса путём организации разрешающего взаимодействия между владельцем ресурса и службой HTTP или стороннему приложению от своего имени. Данная спецификация заменяет и отменяет протокол OAuth 1.0, описанный в RFC 5849.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 5741.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc6749.

Авторские права

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

В традиционной модели аутентификации «клиент-сервер» клиент запрашивает ресурс с ограниченным доступом (защищённый ресурс) на сервере с предоставлением учётных данных, известных серверу (зарегистрированных). Для предоставления сторонним приложениям доступа к ресурсам с ограничениями владелец раскрывает учётные данные (credentials) третьей стороне. С этим связаны указанные ниже проблемы и ограничения.

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

OAuth устраняет отмеченные недостатки путём введения уровня предоставления полномочий (authorization layer) и разделения ролей клиента и владельца ресурса. В Oauth клиент запрашивает доступ к ресурсам владельца, поддерживаемым на сервере, и вводит свои учётные данные, отличные от учётных данных владельца ресурса.

Вместо использования учётной записи владельца защищённого ресурса клиент получает маркер доступа (access token) — строку, обозначающую определённую область доступа, срок действия и другие атрибуты доступа. Маркеры доступа сторонним клиентам предоставляет сервер авторизации, уполномоченный владельцем ресурса. Клиент указывает свой маркер для получения доступа к защищённым ресурсам, размещённым на сервере.

Например, конечный пользователь (владелец ресурса) может предоставить службе печати (клиент) доступ к своим фотографиям, хранящимся на сервере обмена снимками (сервер ресурсов), без раскрытия службе печати своего имени (username) и пароля. Аутентификация выполняется непосредственно на сервере, которому доверяет служба обмена снимками (сервер авторизации), путём предоставления конкретных свидетельств (credentials) — маркера доступа.

Эта спецификация предназначена для использования с протоколом HTTP ([RFC2616]). Применение OAuth с другими протоколами выходит за рамки документа.

Протокол OAuth 1.0 ([RFC5849], опубликованный как информационный документ) является результатом работы небольшого специализированного сообщества. Данная спецификация категории Standards Track основана на опыте внедрения OAuth 1.0, а также дополнительных вариантах применения и требованиях по расширяемости, собранных в широком сообществе IETF. Протокол OAuth 2.0 не совместим с OAuth 1.0. Протоколы могут сосуществовать в сети, а реализации могут поддерживать обе версии. Однако цель данной спецификации заключается в том, чтобы новые реализации поддерживали OAuth 2.0 в соответствии с этим документом, а версия OAuth 1.0 сохранялась бы только для поддержки имеющихся внедрений. Протокол OAuth 2.0 в деталях реализации имеет мало общего с OAuth 1.0. Разработчикам, знакомым с OAuth 1.0, не следует относить имеющиеся у них представления о структуре и деталях работы к новому протоколу.

1.1. Роли

В OAuth определены 4 роли, описанные ниже.

resource owner — владелец ресурса

Сущность (субъект), способная разрешить доступ к защищённому ресурсу. Если ресурс принадлежит частному лицу, владелец именуется конечным пользователем (end-user).

resource server — сервер ресурсов

Сервер, на котором размещены защищённые ресурсы, способный воспринимать запросы к этим ресурсам и отвечать на запросы с маркером доступа.

client — клиент

Приложение, запрашивающее доступ к защищённому ресурсу от имени и с позволения (авторизации) владельца данного ресурса. Термин «клиент» не предполагает каких-либо конкретных характеристик реализации (например, это может быть приложение не сервере, настольном компьютере или ином устройстве).

authorization server — сервер авторизации (предоставления полномочий)

Сервер, выдающий клиентам маркеры доступа после успешной проверки подлинности (аутентификации) владельцем ресурса и предоставления прав доступа.

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

1.2. Поток протокола

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Владелец    |
|        |                               |   ресурса     |
|        |<-(B)-- Authorization Grant ---|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(C)-- Authorization Grant -->|     Сервер    |
| Клиент |                               |  авторизации  |
|        |<-(D)----- Access Token -------|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(E)----- Access Token ------>|     Сервер    |
|        |                               |    ресурсов   |
|        |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

Рисунок 1. Абстрактный поток протокола.

Абстрактный поток обмена OAuth 2.0 показан на рисунке 1 для иллюстрации взаимодействия ролей.

Клиент запрашивает разрешение (авторизацию) у владельца ресурса. Запрос может направляться напрямую владельцу ресурса (как показано на рисунке) или (предпочтительно) через сервер авторизации (посредник).
Клиент получает разрешение, представляющее собой учётные данные владельца ресурса, выраженные одним из 4 типов, заданных этой спецификацией, или с использованием расширения. Тип разрешения зависит от выбранного клиентом метода запроса и поддерживаемых сервером авторизации типов.
Клиент запрашивает маркер доступа, подтверждая свою подлинность серверу авторизации и представляя полученное разрешение.
Сервер авторизации проверяет подлинность клиента и действительность разрешения, выдавая (или не выдавая) маркер доступа по результатам проверки.
Клиент запрашивает защищённый ресурс у сервера ресурсов и аутентифицируется по маркеру доступа.
Сервер ресурсов проверяет маркер доступа и обслуживает или отвергает запрос по результатам проверки.

Предпочтительным методом получения разрешения (этапы (A) и (B) на рисунке) является использование сервера авторизации в качестве посредника, как показано на рисунке 3 в параграфе 4.1.

1.3. Разрешение

Разрешение (authorization grant) — это учётные данные, представляющие собой авторизацию владельца ресурса (для доступа к защищённым ресурсам), которые клиент применяет для получения маркера доступа. Данная спецификация определяет 4 типа разрешений — код авторизации (authorization code), неявное разрешение (implicit), учётные данные владельца ресурса и учётные данные клиента. Задан также механизм расширения для определения новых типов.

1.3.1. Код авторизации

Код авторизации получается с использованием сервера авторизации, служащего посредником между клиентом и владельцем ресурса. Вместо запроса авторизации напрямую у владельца ресурса, клиент направляет владельца на сервер авторизации (через пользовательский агент, как указано в [RFC2616]), который, в свою очередь, направляет владельца обратно к клиенту с кодом авторизации.

Перед тем как направить владельца ресурса к клиенту с кодом авторизации, сервер авторизации проверяет подлинность владельца ресурса и получает разрешение (авторизацию). Поскольку владелец ресурса аутентифицируется лишь на сервере авторизации, клиент не получает учётных данных владельца ресурса.

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

1.3.2. Неявное разрешение

Неявное разрешение — это упрощённый поток кода авторизации, оптимизированный для клиентов, реализованных в браузере с использованием языка сценариев, такого как JavaScript. В этом случае клиенту вместо кода авторизации напрямую выдаётся маркер доступа (как результат авторизации владельца ресурса). Разрешение представляется неявным, поскольку не выдаётся промежуточных учётных данных (таких, как код авторизации) и впоследствии такие данные не применяются для получения маркера доступа.

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

Неявные разрешения сокращают время отклика и повышают эффективность для некоторых клиентов (таких, как клиенты, реализованные для приложений, исполняемых в браузере), поскольку снижают число обходов, требуемых для получения маркера доступа. Однако полученное удобство следует сопоставлять с последствиями для безопасности, такими, как описаны в параграфах 10.3 и 10.16, особенно при доступности типа «код авторизации».

1.3.3. Учётные данные владельца ресурса

Учётные данные владельца ресурса (т. е. имя пользователя и пароль) могут использоваться напрямую как разрешение для получения маркера доступа. Такие данные следует использовать лишь при высоком уровне доверия между владельцем ресурса и клиентом (например, когда клиент является частью операционной системы устройства или привилегированным приложением), а другие типы разрешений (такие, как код авторизации) недоступны.

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

1.3.4. Учётные данные клиента

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

1.4. Маркер доступа

Маркер доступа (access token) — это свидетельства, представляемые для доступа к защищённым ресурсам. Маркер представляет собой строку разрешения, предоставленного клиенту (клиент не анализирует эту строку). Маркеры имеют конкретные области и сроки действия, предоставленные владельцем ресурса и применяемые сервером ресурсов и сервером авторизации.

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

Маркер доступа обеспечивает уровень абстракции, заменяющий различные модели авторизации (например, имя и пароль) одним маркером, понятным серверу ресурсов. Такая абстракция позволяет выдавать маркеры доступа с более жёсткими ограничениями, нежели разрешение на получение маркера, а также избавляет серверы ресурсов от необходимости понимать множество методов аутентификации.

Маркеры доступа могут иметь разный формат, структуру и методы применения (например, криптографические свойства) в зависимости от требований безопасности сервера ресурсов. Атрибуты маркеров и методы, применяемые для доступа к защищённым ресурсам, выходят за рамки данной спецификации и задаются отдельными документами, такими как [RFC6750].

1.5. Маркер обновления

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

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

+--------+                                           +---------------+
|        |--(A)------- Authorization Grant --------->|               |
|        |                                           |               |
|        |<-(B)----------- Access Token -------------|               |
|        |               & Refresh Token             |               |
|        |                                           |               |
|        |                            +----------+   |               |
|        |--(C)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(D)- Protected Resource --|  Сервер  |   |    Сервер     |
| Клиент |                            | ресурсов |   |  авторизации  |
|        |--(E)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(F)- Invalid Token Error -|          |   |               |
|        |                            +----------+   |               |
|        |                                           |               |
|        |--(G)----------- Refresh Token ----------->|               |
|        |                                           |               |
|        |<-(H)----------- Access Token -------------|               |
+--------+           & Optional Refresh Token        +---------------+

Рисунок 2. Обновление устаревшего маркера доступа.

Поток обновления показан на рисунке 2 и включает описанные ниже этапы.

Клиент запрашивает маркер доступа, аутентифицируясь на сервере авторизации и представляя разрешение.
Сервер авторизации проверяет подлинность клиента и разрешение, выдавая при их действительности маркеры доступа и обновления.
Клиент обращается к защищённому ресурсу на сервере ресурса, представляя маркер доступа.
Сервер ресурсов проверяет маркер доступа и при действительности маркера обслуживает запрос.
Этапы (C) и (D) повторяются, пока не завершится срок действия маркера доступа. Если клиент знает, что срок действия маркера истёк, он переходит к этапу (G), в ином случае — отправляет ресурсу другой запрос.
Если маркер доступа недействителен, сервер ресурсов возвращает ошибку (invalid token).
Клиент запрашивает новый маркер доступа, аутентифицируясь на сервере авторизации и представляя маркер обновления. Требования к аутентификации зависят от типа клиента и политики сервера авторизации.
Сервер авторизации проверяет подлинность клиента и маркер обновления, выдавая при их действительности новый маркер доступа, который может сопровождаться новым маркером обновления.

Этапы (C), (D), (E), (F) выходят за рамки этой спецификации, как указано в разделе 7.

1.6. Версия TLS

При использовании защиты на транспортном уровне (Transport Layer Security или TLS) в этом документе предполагается, что версия TLS может меняться с течением времён в зависимости от распространённости и известных уязвимостей. На момент создания этого документа наиболее свежей была версия TLS 1.2 [RFC5246], но она ещё не получила широкого распространения и может оказаться недоступной для внедрения. Версия TLS 1.0 [RFC2246] распространена наиболее широко и обеспечит максимально широкую совместимость. Реализации могут также поддерживать дополнительные механизмы защиты на транспортном уровне, отвечающие требованиям безопасности.

1.7. Перенаправления HTTP

В этой спецификации широко применяется перенаправление HTTP, когда клиент или сервер авторизации направляет пользовательский агент владельца ресурса в другое место. Хотя в примерах данной спецификации используется код статуса HTTP 302, допускаются и другие методы, доступные пользовательскому агенту для перенаправления и являющиеся свойством реализации.

1.8. Функциональная совместимость

OAuth 2.0 предоставляет эффективную авторизацию с чётко определёнными свойствами безопасности. Однако большой набор средств и расширяемость модели дополнительными компонентами, вероятно, приведут к появлению большого числа несовместимых реализаций. Кроме того, спецификация оставляет некоторые требуемые компоненты (например, регистрацию клиентов, возможности сервера, обнаружение конечных точек) частично или полностью неопределёнными. Без этих компонентов потребуется специально настраивать клиент вручную для конкретного сервера авторизации и сервера ресурсов, чтобы обеспечить функциональную совместимость.

Описываемая здесь схема разработана с ожиданием того, что в последующих работах будут заданы чёткие профили и расширения для обеспечения полной совместимости в масштабах web-системы.

1.9. Соглашения о нотации

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119 [RFC2119].

В этой спецификации применяется нотация ABNF⁴ [RFC5234], а также включено правило ссылок URI из Uniform Resource Identifier (URI): Generic Syntax [RFC3986].

Некоторые термины, связанные с безопасностью, следует трактовать в соответствии с [RFC4949]. К таким терминам относятся attack (атака), authentication (аутентификация, проверка подлинности), authorization (авторизация, проверка и предоставление полномочий), certificate (сертификат), confidentiality (конфиденциальность), credential (свидетельство, учётные данные), encryption (шифрование), identity (отождествление), sign (подпись), signature (подпись), trust (доверие), validate (проверка, валидация), verify (проверка, подтверждение) и др.

Если явно не указано иное, регистр символов в именах и значениях параметров принимается во внимание.

2. Регистрация клиента

До начала использования протокола клиент регистрируется на сервере авторизации. Методы регистрации выходят за рамки документа, но обычно регистрация выполняется путём взаимодействия разработчика конечного пользователя с HTML-формой. Регистрация не требует прямого взаимодействия клиента с сервером авторизации. Если сервер авторизации поддерживает регистрацию, она может основываться на иных способах организации доверия и получения требуемых свойств клиента (например, URI перенаправления, тип клиента). Регистрация может осуществляться, например, с использованием собственного или стороннего подтверждения или путём обнаружения клиента сервером авторизации по доверенному каналу.

Для регистрации клиента разработчику клиента нужно:

указать тип клиента, как описано в параграфе 2.1;
предоставить URI перенаправления для клиента, как описано в параграфе 3.1.2;
включить другие сведения, требуемые сервером авторизации (например, имя приложения, web-сайт, описание, логотип, принятие правовых условий).

2.1. Типы клиентов

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

confidential — конфиденциальные

Клиенты, способные обеспечить конфиденциальность своих учётных данных (например, клиенты, реализованные на защищённом сервере с ограниченным доступом к учётным записям) или защитить свою аутентификацию иными средствами.

public — публичные

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

Назначение типа клиента основывается на определении безопасной проверки подлинности на сервере авторизации и допустимом уровне раскрытия учётной записи клиента. Серверу авторизации не следует делать предположений о типе клиента.

Клиент может быть реализован как распределенный набор компонентов, каждый из которых имеет свой тип и контекст защиты (например, клиент с защищённым компонентом на сервере и открытым в браузере). Если сервер авторизации не поддерживает регистрацию таких клиентов, ему следует регистрировать каждый компонент отдельно.

Данная спецификация разработана для указанных ниже профилей клиентов.

web application — web-приложение

Конфиденциальный клиент, работающий на web-сервере. Владельцы ресурсов обращаются к клиенту через пользовательский интерфейс HTML, отображаемый в пользовательский агент на устройстве, применяемом владельцем ресурса. Учётные данные клиента и выданный клиенту маркер доступа хранятся на web-сервере, не раскрываются владельцу ресурса и не доступны ему.

user-agent-based application — приложение на основе пользовательского агента

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

native application — естественное приложение

Публичный клиент, установленный и исполняющийся на устройстве владельца ресурса. Данные протокола и свидетельства доступны владельцу ресурса. Предполагается, что аутентификационные свидетельства клиента, включённые в приложение, могут быть извлечены. С другой стороны, выданным динамически учётным данным, таким как маркеры доступа и обновления, можно обеспечить должный уровень защиты. Эти учётные данные, как минимум, защищены от враждебных серверов, с которыми приложение может взаимодействовать. На некоторых платформах учётные данные могут быть защищены даже от приложений, размещённых на том же устройстве.

2.2. Идентификатор клиента

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

Спецификация не задаёт размер строки идентификатора и клиентам следует избегать допущений о её размере. Серверам авторизации следует документировать размер выдаваемых идентификаторов.

2.3. Проверка подлинности клиента

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

Конфиденциальным клиентам обычно выдаётся (или организуется) набор клиентских свидетельств (учётных данных) для аутентификации на сервере авторизации (например, пароль или пара ключей — открытый и секретный).

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

Клиенту недопустимо применять в запросе более одного метода аутентификации.

2.3.1. Пароль клиента

Клиенты, владеющие паролем, могут применять схему HTTP Basic authentication, описанную в [RFC2617], для аутентификации на сервере авторизации. Идентификатор клиента кодируется с использованием алгоритма application/x-www-form-urlencoded, описанного в Приложении B, а закодированное значение служит именем пользователя. Пароль клиента кодируется тем же алгоритмом и служит прямому назначению⁶. Значения URI кодируются в соответствии с [RFC2617]⁷. Сервер авторизации должен поддерживать базовую аутентификацию HTTP для клиентов, которым был выдан пароль. Ниже приведён пример базовой аутентификации.

     Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

В дополнение к этому⁸ сервер авторизации может поддерживать включение учётных данных клиента в тело запроса с использованием указанных ниже параметров.

client_id

Обязательно. Идентификатор, выданный клиенту при регистрации, как описано в параграфе 2.2.

client_secret

Обязательно. Секрет клиента. Клиент может опустить этот параметр, если срока его секрета пуста.

Включение учётных данных клиента в тело запроса не рекомендуется и его следует разрешать лишь клиентам, не способным напрямую использовать базовую аутентификацию HTTP (или иную аутентификацию HTTP по паролю). Параметры можно передавать только в теле запроса и недопустимо включать их в URI запроса.

Например, запрос на обновление маркера доступа (раздел 6) с использованием параметров в теле запроса имеет вид:

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
     &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw⁹

Сервер авторизации должен требовать использования TLS (см. параграф 1.6) при передаче запросов с аутентификацией по паролю. Поскольку данный метод проверки подлинности включает пароль, сервер должен защищать использующие этот метод конечные точки от атак с подбором пароля (brute force).

2.3.2. Другие методы аутентификации

Сервер авторизации может поддерживать любые схемы аутентификации HTTP, соответствующие его требованиям безопасности. При использовании таких методов проверки подлинности сервер должен задать сопоставление идентификаторов клиентов (записей о регистрации) со схемой аутентификации.

2.4. Незарегистрированные клиенты

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

3. Конечные точки протокола

В процессе предоставления полномочий используются 2 конечные точки сервера авторизации (ресурсы HTTP):

конечная точка авторизации (authorization endpoint) используется клиентом для получения разрешений от владельца ресурса через перенаправление пользовательского агента;
конечная точка маркера (token endpoint) используется клиентом для обмена разрешения на маркер доступа (обычно с аутентификацией клиента).

Используется также конечная точка клиента:

конечная точка перенаправления (redirection endpoint) используется сервером авторизации для возврата клиентам откликов с учётными данными через пользовательский агент владельца ресурса.

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

3.1. Конечная точка авторизации

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

URI конечной точки может включать компонент query (параграф 3.4 в [RFC3986]) в формате application/x-www-form-urlencoded (Приложение B), который должен сохраняться при добавлении в запрос других параметров. В URI конечной точки недопустимо включать компонент fragment.

Поскольку запрос к конечной точке авторизации ведёт к аутентификации пользователя и передаче учётных данных в открытом виде (отклик HTTP), сервер авторизации должен требовать использования TLS (параграф 1.6), при передаче запросов к конечной точке авторизации.

Сервер авторизации должен поддерживать использование метода HTTP GET [RFC2616] для конечной точки авторизации и может также поддерживать метод POST.

Параметры, передаваемые без значения, должны обрабатываться как отсутствующие в запросе. Сервер авторизации должен игнорировать непонятные параметры запроса. Параметры запросов и откликов, заданные в этой спецификации¹⁰, недопустимо включать более одного раза.

3.1.1. Типы откликов

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

response_type

Обязательно. Значением параметра должно быть одно из значений: code для запроса кода авторизации (параграф 4.1.1), token для запроса маркера доступа (неявное разрешение, параграф 4.2.1) или значение зарегистрированного расширения (параграф 8.4).

Типы расширенных откликов могут включать список разделённых пробелом (%x20) значений, порядок которых не имеет значения (например, тип «a b» эквивалентен типу «b a»). Назначение таких композитных откликов определяется соответствующими спецификациями.

Если в запросе авторизации отсутствует параметр response_type или тип запроса не понятен, сервер авторизации должен возвращать отклик об ошибке, как указано в параграфе 4.1.2.1.

3.1.2. Конечная точка перенаправления

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

Значение URI конечной точки перенаправления должно быть абсолютным URI в соответствии с параграфом 4.3 в [RFC3986]. URI конечной точки может включать компонент query (параграф 3.4 в [RFC3986]) в форме application/x-www-form-urlencoded (Приложение B), который должен сохраняться при добавлении параметров в запрос. В URI конечной точки недопустимо включать компонент fragment.

3.1.2.1. Конфиденциальность запроса конечной точки

Для конечной точки перенаправления следует требовать использования TLS (параграф 1.6) при типе запроса code или token, а также в случаях, когда запрос перенаправления ведёт к передаче конфиденциальных учётных данных через открытую сеть. Эта спецификация не требует использовать TLS, поскольку на момент создания документа такое требование стало бы существенным препятствием для многих разработчиков клиентов. При отсутствии возможности использовать TLS серверу авторизации следует предупреждать владельца ресурса о незащищённой конечной точке до перенаправления (например, выводом сообщения в процессе запроса авторизации).

Отсутствие защиты на транспортном уровне может оказывать существенное влияние на безопасность клиента и защищённых ресурсов, к которым клиент получает доступ. Применение защиты на транспортом уровне особенно важно при использовании процесса авторизации как делегированной клиентом аутентификации конечного пользователя (например, для сторонней службы входа в систему — sign-in).

3.1.2.2. Требования к регистрации

Сервер авторизации должен требовать регистрации конечных точек перенаправления от:

публичных клиентов;
конфиденциальных клиентов, использующих неявные разрешения (implicit grant type).

Серверу авторизации следует требовать от всех клиентов регистрации конечной точки перенаправления до использования конечной точки авторизации.

Серверу авторизации следует требовать от клиента предоставления полного URI перенаправления (клиент может использовать параметр запроса state для настройки на уровне запроса). Если потребовать регистрации полного URI перенаправления невозможно, серверу следует требовать регистрации схемы URI, полномочий (authority) и пути (позволяя клиенту динамически менять при запросе полномочий лишь компонент query в URI перенаправления).

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

Отсутствие требования регистрации URI перенаправления может позволить злоумышленнику использовать конечную точку авторизации в качестве открытого редиректора (см. параграф 10.15).

3.1.2.3. Динамическая настройка

Если зарегистрировано несколько URI перенаправления, задана лишь часть URI или URI перенаправления не зарегистрирован, клиент должен включить URI перенаправления в запрос авторизации, используя параметр запроса redirect_uri.

При наличии в запросе URI перенаправления сервер авторизации должен сопоставлять полученное значение с зарегистрированными URI (или компонентами URI) при их наличии, как указано в разделе 6 [RFC3986]. Если регистрация клиента включала полное значение URI перенаправления, сервер авторизации должен сравнивать URI, как описано в параграфе 6.2.1 [RFC3986].

3.1.2.4. Недействительная конечная точка

Если запрос авторизации не прошёл проверку из-за отсутствия, непригодности или несоответствия URI перенаправления, серверу авторизации следует информировать владельца ресурса и недопустимо автоматически направлять агент пользователя на недействительный URI перенаправления.

3.1.2.5. Содержимое конечной точки

Запрос перенаправления в конечную точку клиента обычно ведёт к получению отклика в форме документа HTML, который обрабатывается агентом пользователя. Если отклик HTML предоставляется непосредственно в результате запроса перенаправления, любой сценарий в документе HTML будет выполняться с полным доступом к URI перенаправления и содержащимся в нем учётным данным.

Клиенту не следует включать сторонние сценарии (например, аналитику, социальные плагины, рекламные сети) в отклик с конечной точкой перенаправления. Вместо этого следует извлечь учётные данные из URI и перенаправить агент пользователя в другую конечную точку без раскрытия учётных данных (ни в URI, ни в ином месте). Если сторонние сценарии включены, клиент должен убедиться, что сначала будет выполнены его сценарии (для извлечения и удаления учётных данных из URI).

3.2. Конечная точка маркера

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

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

URI конечной точки может включать компонент query (параграф 3.4 в [RFC3986]) в форме application/x-www-form-urlencoded (Приложение B), который должен сохраняться при добавлении параметров в запрос. В URI конечной точки недопустимо включать компонент fragment.

Поскольку запрос конечной точки маркера ведёт к передаче учётных данных в открытом виде (в запросе или отклике HTTP), сервер авторизации должен требовать использования TLS (параграф 1.6).

Клиент при запросе маркера доступа должен использовать метод HTTP POST.

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

3.2.1. Проверка подлинности клиента

При запросе конечной точки маркера конфиденциальные и иные клиенты, представляющие учётные данные, должны аутентифицироваться на сервере авторизации, как указано в параграфе 2.3, Цели аутентификации указаны ниже.

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

Публичные клиенты¹² могут применять параметр запроса client_id для идентификации себя при отправке запросов конечной точки маркера. В запросе authorization_code и grant_type для конечной точки маркера неаутентифицированные клиенты должны указывать значение client_id во избежание случайного восприятия чужого кода. Это защищает клиента от подмены кода аутентификации (но не обеспечивает дополнительной защиты ресурса).

3.3. Область действия маркера доступа

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

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

     scope       = scope-token *( SP scope-token )
     scope-token = 1*( %x21 / %x23-5B / %x5D-7E )

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

Если клиент не включает параметр scope в запрос авторизации, сервер авторизации должен обработать запрос с использованием принятого по умолчанию значения или отклонить запрос, указав ошибку (invalid scope). Серверу авторизации следует указывать в документации требования к области действия и принятое по умолчанию значение (если оно задано).

4. Получение прав доступа (авторизация)

Для запроса маркера доступа клиент получает согласие (авторизацию) от владельца ресурса, выражаемое в форме разрешения (authorization grant), которое клиент использует для запроса маркера доступа. В OAuth определены 4 типа разрешений: authorization code (код авторизации), implicit (неявное), resource owner password credentials (учётные данные владельца ресурса) и client credentials (учётные данные клиента). Обеспечивается также механизм расширения для задания новых типов разрешения.

4.1. Код авторизации

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

+----------+
| Владелец |
| ресурса  |
|          |
+----------+
     ^
     |
    (B)
+----|-----+          Client Identifier      +---------------+
|         -+----(A)-- & Redirection URI ---->|               |
|  Агент   |                                 |     Сервер    |
| пользов.-+----(B)-- User authenticates --->|  авторизации  |
|          |                                 |               |
|         -+----(C)-- Authorization Code ---<|               |
+-|----|---+                                 +---------------+
  |    |                                         ^      v
 (A)  (C)                                        |      |
  |    |                                         |      |
  ^    v                                         |      |
+---------+                                      |      |
|         |>---(D)-- Authorization Code ---------'      |
|  Клиент |          & Redirection URI                  |
|         |                                             |
|         |<---(E)----- Access Token -------------------'
+---------+       (w/ Optional Refresh Token)

Строки этапов A), (B) и (C) разбиты на 2 части, поскольку они проходят через пользовательский агент.

Рисунок 3. Поток кода авторизации.

Этапы потока, показанного на рисунке 3, описаны ниже.

Клиент инициирует поток, направляя пользовательский агент владельца ресурса в конечную точку авторизации. Клиент включает в запрос свой идентификатор, запрашиваемую область действия, локальное состояние и URI перенаправления, куда сервер авторизации направит агент пользователя по результатам проверки полномочий.
Сервер авторизации проверяет запрос на предмет наличия и корректности всех параметров. Если запрос корректен, сервер авторизации аутентифицирует владельца ресурса и получает решение в части прав доступа (через пользовательский агент владельца ресурса или иные средства подтверждения)¹³.
В предположении, что владелец разрешает доступ, сервер авторизации направляет пользовательский агент к клиенту, используя предоставленный ранее (в запросе или при регистрации клиента) URI перенаправления. URI перенаправления включает код авторизации и локальное состояние, указанное клиентом ранее.
Клиент запрашивает маркер доступа у конечной точки маркеров сервера авторизации, включая полученный на предыдущим этапе код авторизации. При запросе клиент аутентифицируется на сервере авторизации. Клиент включает для проверки URI перенаправления, использованный для получения кода кода авторизации.
Сервер авторизации проверяет подлинность клиента, его код авторизации и убеждается, что полученный URI перенаправления совпадает с URI, использованным для направления (пользовательского агента владельца ресурса¹⁴) к клиенту на этапе (C). При положительном результате проверки сервер авторизации отвечает маркером доступа, который может быть дополнен маркером обновления.

4.1.1. Запрос авторизации

Клиент создаёт URI запроса, добавляя указанные ниже параметры в компонент query URI конечной точки авторизации в форме application/x-www-form-urlencoded (Приложение B).

response_type

Обязательно и должно иметь значение code.

client_id

Обязательно. Идентификатор клиента, описанный в параграфе 2.2.

redirect_uri

Необязательно (см. параграф 3.1.2).

scope

Необязательно. Область действия запроса доступа (параграф 3.3).

state

Рекомендуется. Неанализируемое (opaque) значение, используемое клиентом для поддержки состояния между запросом и обратным вызовом (callback). Сервер авторизации включает это значение при перенаправлении агента пользователя обратно к клиенту. Этот параметр следует применять для предотвращения кросс-сайтовой подделки запросов, как указано в параграфе 10.12.

Клиент направляет владельца ресурса по созданному URI, используя отклик перенаправления HTTP или иные средства, доступные ему через пользовательский агент. Например, клиент направляет агент пользователя на указанный ниже запрос HTTP с использованием TLS.

    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

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

Когда решение принято, сервер авторизации направляет агент пользователя по указанному клиентом URI перенаправления, используя отклик перенаправления HTTP или иной доступный пользовательскому агенту способ.

4.1.2. Отклик с предоставлением полномочий

Если владелец ресурса одобряет (принимает) запрос доступа, сервер авторизации выдаёт код авторизации и доставляет его клиенту, добавляя указанные ниже параметры в компонент query URI перенаправления в формате application/x-www-form-urlencoded (Приложение B).

code

Обязательно. Код авторизации, выданный сервером авторизации. Срок действия кода должен завершаться вскоре после выдачи, чтобы смягчить риск утечек. Рекомендуется устанавливать срок действия не более 10 минут. Клиенту недопустимо использовать код авторизации более 1 раза. При повторном использовании кода авторизации сервер авторизации должен отвергать запрос и следует также (по возможности) отозвать все маркеры, выданные ранее на основе этого кода. Код авторизации привязывается к идентификатору клиента и URI перенаправления.

State

Обязательно, если в запросе клиента был указан параметр state. Значение поля берётся из запроса клиента.

Например, сервер авторизации будет перенаправлять агент пользователя, передавая показанный ниже отклик HTTP.

     HTTP/1.1 302 Found
     Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
               &state=xyz

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

4.1.2.1. Отклик об ошибке

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

Если владелец ресурса отвергает запрос доступа или запрос не может быть выполнен по причинам, отличным от отсутствия или непригодности URI перенаправления, сервер авторизации информирует клиента, добавляя указанные ниже параметры в URI перенаправления с использованием формата application/x-www-form-urlencoded (Приложение B).

error

Обязательно. Одна из приведённых ниже строк ASCII [USASCII] с кодом ошибки:

invalid_request

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

unauthorized_client

У клиента нет полномочий запрашивать код авторизации с использованием этого метода.

access_denied

Владелец ресурса или сервер авторизации отклонил запрос.

unsupported_response_type

Сервер авторизации не поддерживает получение кода авторизации этим методом.

invalid_scope

Запрошенная область действия некорректна, неизвестна или имеет ошибочную форму.

server_error

На сервере авторизации возникла непредвиденная ситуация, не позволившая выполнить запрос (этот код нужен потому, что код HTTP 500 Internal Server Error невозможно возвратить клиенту через перенаправление HTTP).

temporarily_unavailable

Сервер авторизации в данный момент не способен обслужить запрос из-за временной перегрузки или обслуживания сервера (этот код нужен потому, что код HTTP 503 Service Unavailable невозможно возвратить клиенту через перенаправление HTTP).

В значение параметра error недопустимо включать символы, отличные от %x20-21 / %x23-5B / %x5D-7E.

error_description

Необязательно. Понятный человеку текст ASCII [USASCII] с дополнительными сведениями, помогающими разработчику клиента понять причину ошибки. В значение параметра error_description недопустимо включать символы, отличные от %x20-21 / %x23-5B / %x5D-7E.

error_uri

Необязательно. Значение URI, указывающее понятную человеку web-страницу с дополнительными сведениями, позволяющими разработчику клиента понять причину ошибки. Значение параметра error_uri должно соответствовать синтаксису URI-ссылок, поэтому в него недопустимо включать символы, отличные от %x20-21 / %x23-5B / %x5D-7E.

state

Обязательно, если в запросе авторизации был параметр state. Значение берётся из запроса клиента.

Например, сервер авторизации может перенаправить агент пользователя, передав ему отклик HTTP

   HTTP/1.1 302 Found
   Location: https://client.example.com/cb?error=access_denied&state=xyz

4.1.3. Запрос маркера доступа

Клиент передаёт конечной точке маркер, включая указанные ниже параметры в тело запроса HTTP в формате application/x-www-form-urlencoded (Приложение B) с кодировкой символов UTF-8.

grant_type

Обязательно и должно иметь значение authorization_code.

code

Обязательно. Код авторизации, полученный от сервера авторизации.

redirect_uri

Обязательно, если в запрос авторизации был включён параметр redirect_uri (см. параграф 4.1.1) Значения redirect_uri должны быть идентичными.

client_id

Обязательно, если клиент не аутентифицируется на сервере авторизации, как указано в параграфе 3.2.1.

Если клиент является конфиденциальным или ему были выданы учётные данные (или применяются иные требования аутентификации), клиент должен пройти аутентификацию на сервере авторизации, как указано в параграфе 3.2.1.

Например, клиент подаёт приведённый ниже запрос HTTP с использованием TLS.

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
     &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Сервер авторизации должен:

требовать аутентификацию конфиденциальных клиентов и любых клиентов, которым были выданы учётные данные (или применяются иные требования аутентификации);
аутентифицировать клиента, если включена аутентификация клиентов;
убедиться, что код авторизации был выдан аутентифицированному конфиденциальному клиенту или (для публичных клиентов) убедиться, что код был выдан для client_id, указаного в запросе;
проверить действительность кода авторизации;
убедиться в наличии параметра redirect_uri, если в исходный запрос авторизации (см. параграф 4.1.1) был включён одноимённый параметр, а также убедиться в совпадении значений параметра.

4.1.4. Отклик с маркером доступа

Если запрос маркера доступа корректен и авторизован (полномочия предоставлены), сервер авторизации выдаёт маркер доступа, который может сопровождаться маркером обновления, как описано в параграфе 5.1. Если запрос аутентификации клиента отвергнут или непригоден, сервер авторизации возвращает отклик об ошибке (параграф 5.2).

Ниже приведён пример отклика при успешном выполнении запроса.

     HTTP/1.1 200 OK
     Content-Type: application/json¹⁵
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

4.2. Неявное разрешение

Тип неявного предоставления доступа служит для получения маркера доступа (без маркера обновления) и оптимизирован для публичных клиентов с известным URI перенаправления. Такие клиенты обычно реализованы в браузере с использованием языка сценариев, такого как JavaScript.

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

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

Неявное разрешение не включает аутентификацию клиента и полагается на присутствие владельца ресурса и регистрацию URI перенаправления. Поскольку маркер доступа кодируется в URI перенаправления, он может раскрываться владельцу ресурса и другим приложениям на том же устройстве.

+----------+
| Владелец |
| ресурса  |
|          |
+----------+
     ^
     |
    (B)
+----|-----+          Client Identifier     +---------------+
|         -+----(A)-- & Redirection URI --->|               |
|  Агент   |                                |     Сервер    |
| пользов.-|----(B)-- User authenticates -->|  авторизации  |
|          |                                |               |
|          |<---(C)--- Redirection URI ----<|               |
|          |          with Access Token     +---------------+
|          |            in Fragment
|          |                                +---------------+
|          |----(D)--- Redirection URI ---->|    Ресурс     |
|          |          without Fragment      |    клиента    |
|          |                                |    в Web      |
|     (F)  |<---(E)------- Script ---------<|               |
|          |                                +---------------+
+-|--------+
  |    |
 (A)  (G) Access Token
  |    |
  ^    v
+---------+
|         |
|  Клиент |
|         |
+---------+

Строки этапов (A) и (B) разбиты на 2 части, поскольку они проходят через пользовательский агент.

Рисунок 4. Поток неявного разрешения.

Поток обмена для этого типа разрешения показан на рисунке 4.

Клиент запускает процесс, направляя пользовательский агент владельца ресурса в конечную точку авторизации, включая в запрос свой идентификатор, запрашиваемую область действия, локальное состояние и URI перенаправления, куда сервер авторизации будет направлять пользовательский агент после принятия или отклонения запроса.
Сервер авторизации проверяет подлинность владельца ресурса (через пользовательский агент) и определяет, принял ли (или отклонил) владелец запрос клиента на доступ.
Предполагая, что владелец разрешил доступ, сервер авторизации перенаправляет пользовательский агент обратно к клиенту по полученному ранее URI перенаправления (URI включает маркер доступа в параметре fragment).
Пользовательский агент следует инструкциям по перенаправлению, выполняя запрос к размещённому в web ресурсу клиента (перенаправление не включает fragment в соответствии с [RFC2616]). Пользовательский агент сохраняет сведения fragment локально.
Клиентский web-ресурс возвращает web-страницу (обычно документ HTML со встроенным сценарием), способную обратиться к полному URI перенаправления, включая значение fragment, хранящееся у пользовательского агента, и извлечь из fragment маркер доступа (и другие параметры).
Пользовательский агент локально выполняет сценарий, предоставленный web-ресурсом клиента и извлекающий маркер доступа.
Пользовательский агент передаёт маркер доступа клиенту.

Важные аспекты безопасности при использовании неявных разрешений описаны в параграфе 1.3.2 и разделе 9.

4.2.1. Запрос разрешения

Клиент создаёт URI запроса, добавляя указанные ниже параметры в URI конечной точки авторизации в формате application/x-www-form-urlencoded (Приложение B).

response_type

Обязательно со значением token.

client_id

Обязательно. Идентификатор клиента, как описано в параграфе 2.2.

redirect_uri

Необязательно (см. параграф 3.1.2).

scope

Необязательно. Область действия запроса доступа, как описано в параграфе 3.3.

state

Клиент направляет владельца ресурса по созданному URI, используя отклик перенаправления HTTP или иные средства, доступные через пользовательский агент.

Например, клиент направляет пользовательский агент на выполнение приведённого ниже запроса HTTP через TLS.

    GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

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

Если запрос корректен, сервер авторизации аутентифицирует владельца ресурса и получает решение о доступе путём запроса к владельцу ресурса или иным подходящим способом. Когда решение принято, сервер аутентификации направляет пользовательский агент по представленному клиентом URI перенаправления, используя отклик перенаправления HTTP или иной способ, доступный через пользовательский агент.

4.2.2. Отклик с маркером доступа

Если владелец ресурса разрешает доступа, сервер авторизации выдаёт маркер доступа и доставляет его клиенту, добавляя указанные ниже параметры в компонент fragment URI перенаправления в формате application/x-www-form-urlencoded (Приложение B).

access_token

Обязательно. Маркер доступа, выданный сервером авторизации.

token_type

Обязательно. Тип выданного маркера (см. параграф 7.1). Регистр символов не учитывается.

expires_in

Рекомендуется. Срок действия маркера в секундах. Например, значение 3600 указывает, что действие маркера прекратится через 1 час с момента генерации отклика. Если параметр не указывается, серверу авторизации следует задавать срок действия иным способом или указывать принятый по умолчанию срок в документации.

scope

Необязательно, если область действия идентична запрошенной клиентом, в остальных случаях обязательно. Область действия маркера доступа описана в параграфе 3.3.

state

Обязательно, если в запросе авторизации был параметр state. Значение берётся из запроса клиента.

Серверу авторизации недопустимо выдавать маркер обновления.

Например, сервер авторизации перенаправляет агент пользователя, передавая HTTP-отклик:

     HTTP/1.1 302 Found
     Location: http://client.example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
               &state=xyz&token_type=example&expires_in=3600¹⁶

Разработчикам следует учитывать, что некоторые пользовательские агенты не поддерживают включение компонента fragment в поле Location заголовка отклика HTTP. Для таких клиентов требуется другой метод перенаправления клиента, отличный от отклика 3xx, например, возврат страницы HTML с кнопкой продолжения (continue), действием которой является перенаправление по URI.

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

4.2.2.1. Отклик с ошибкой

error

Обязательно. Одна строка ASCII [USASCII] с кодом ошибки из числа приведённых ниже.

invalid_request

unauthorized_client

У клиента нет полномочий запрашивать маркер доступа с использованием этого метода.

access_denied

Владелец ресурса или сервер авторизации отклонил запрос.

unsupported_response_type

Сервер авторизации не поддерживает получение маркера доступа этим методом.

invalid_scope

Запрошенная область действия некорректна, неизвестна или имеет ошибочную форму.

server_error

temporarily_unavailable

В значение параметра error недопустимо включать символы, отличные от %x20-21 / %x23-5B / %x5D-7E.

error_description

error_uri

state

Обязательно, если в запросе авторизации был параметр state. Значение берётся из запроса клиента.

Например, сервер авторизации перенаправляет агент пользователя, передавая HTTP-отклик:

   HTTP/1.1 302 Found
   Location: https://client.example.com/cb#error=access_denied&state=xyz

4.3. Разрешение с паролем владельца ресурса

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

Этот тип подходит для клиентов, способных получить учётные данные владельца ресурса (имя пользователя и пароль, обычно с помощью интерактивной формы). Он также применяется для перевода имеющихся клиентов, использующих схемы прямой аутентификации, такие как HTTP Basic (или Digest), на OAuth путём преобразования сохранённых учётных данных в маркер доступа.

+----------+
| Владелец |
| ресурса  |
|          |
+----------+
     v
     |    Resource Owner
    (A) Password Credentials
     |
     v
+---------+                                  +---------------+
|         |>--(B)---- Resource Owner ------->|               |
|         |         Password Credentials     |    Сервер     |
| Клиент  |                                  |  авторизации  |
|         |<--(C)---- Access Token ---------<|               |
|         |    (w/ Optional Refresh Token)   |               |
+---------+                                  +---------------+

Рисунок 5. Resource Owner Password Credentials Flow.

Этапы потока обмена, показанного на рисунке 5, описаны ниже.

Владелец ресурса предоставляет клиенту своё имя пользователя и пароль.
Клиент запрашивает маркер доступа у конечной точки маркеров сервера авторизации, включая полученные от владельца сервиса учётные данные. При запросе сервер авторизации проверяет подлинность клиента.
Сервер авторизации аутентифицирует клиента и проверяет учётные данные владельца. При положительном результате выдаётся маркер доступа.

4.3.1. Запрос авторизации и отклик на него

Метод получения клиентом учётных данных владельца ресурса выходит за рамки этого документа. Клиент должен отбрасывать (удалять) учётные данные после получения маркера доступа.

4.3.2. Запрос маркера доступа

Клиент обращается к конечной точке маркера, добавляя указанные ниже параметры в тело запроса HTTP в формате application/x-www-form-urlencoded (Приложение B) с использованием кодировки символов UTF-8.

grant_type

Обязательно и должно иметь значение password.

username

Обязательно. Имя пользователя (username) для владельца ресурса.

password

Обязательно. Пароль владельца ресурса.

scope

Необязательно. Область действия запроса доступа (см. параграф 3.3).

Если клиент является конфиденциальным или указал свои учётные данные (или иные данные для аутентификации), он должен пройти проверку подлинности на сервере авторизации, как описано в параграфе 3.2.1.

Ниже приведён пример HTTP-запроса клиента с защитой на транспортном уровне.

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=password&username=johndoe&password=A3ddj3w

Сервер авторизации должен:

требовать проверки подлинности для всех конфиденциальных клиентов и клиентов, предоставивших свои учётные данные (или иные данные для аутентификации);
проверить подлинность клиента, если включена аутентификация;
проверить учётные данные владельца ресурса с использованием имеющегося алгоритма проверки паролей.

Поскольку в запросе маркера доступа используется пароль владельца ресурса, сервер авторизации должен защищать конечную точку от атак с подбором пароля (brute force), например, ограничением частоты ввода или предупреждением.

4.3.3. Отклик с маркером доступа

Если запрос маркера доступа действителен и авторизован, сервер авторизации выдаёт маркер доступа, который может сопровождаться маркером обновления, как описано в параграфе 5.1. Если не прошла аутентификация клиента или запрос недействителен, сервер авторизации возвращает отклик с ошибкой, как указано в параграфе 5.2.

Пример отклика об успехе приведён ниже.

     HTTP/1.1 200 OK
     Content-Type: application/json¹⁷
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

4.4. Разрешение с учётными данными клиента

Клиент может запросить маркер доступа, используя лишь свои учётные данные (или иные данные для аутентификации) при запросе доступа к контролируемым им ресурсам или ресурсам другого владельца, предварительно согласованным с сервером авторизации (метод согласования выходит за рамки этого документа).

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

+---------+                                  +---------------+
|         |                                  |               |
|         |>--(A)- Client Authentication --->|     Сервер    |
| Клиент  |                                  |  авторизации  |
|         |<--(B)---- Access Token ---------<|               |
|         |                                  |               |
+---------+                                  +---------------+

Рисунок 6. Поток учётных данных клиента.

Ниже описаны этапы потока обмена, показанного на рисунке 6.

Клиент аутентифицируется на сервере авторизации и запрашивает маркер доступа у конечной точки маркера.
Сервер авторизации проверяет подлинность клиента и при положительном результате выдаёт маркер доступа.

4.4.1. Запрос авторизации и отклик на него

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

4.4.2. Запрос маркера доступа

Клиент обращается к конечной точке маркера, добавляя указанные ниже параметры в тело запроса HTTP в формате application/x-www-form-urlencoded (Приложение B) с кодировкой символов UTF-8.

grant_type

Обязательно и должно иметь значение client_credentials.

scope

Необязательно. Область действия запроса доступа (см. параграф 3.3).

Клиент должен пройти проверку подлинности на сервере авторизации, как описано в параграфе 3.2.1.

Ниже приведён пример HTTP-запроса клиента с защитой на транспортном уровне.

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=client_credentials

Сервер авторизации должен проверить подлинность клиента.

4.4.3. Отклик с маркером доступа

Если запрос маркера доступа действителен и авторизован, сервер авторизации выдаёт маркер доступа, как описано в параграфе 5.1. Маркер обновления включать не следует. Если не прошла аутентификация клиента или запрос недействителен, сервер авторизации возвращает отклик с ошибкой, как указано в параграфе 5.2.

Пример отклика об успехе приведён ниже.

     HTTP/1.1 200 OK
     Content-Type: application/json¹⁸
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "example_parameter":"example_value"
     }

4.5. Расширенные разрешения

Клиент применяет расширенный тип разрешений, указывая его абсолютным URI (задаётся сервером авторизации) в параметре grant_type для конечной точки маркера и при необходимости добавляя дополнительные параметры. Например, для запроса маркера доступа с использованием типа SAML¹⁹ 2.0, как определено в [OAuth-SAML2], клиент может передать показанный ниже запрос HTTP через TLS.

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-
     bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU
     [...опущено для краткости...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-

5. Выдача маркера доступа

Если запрос маркера доступа действителен и авторизован, сервер авторизации выдаёт запрошенный маркер, который может сопровождаться маркером обновления, как описано в параграфе 5.1. Если не прошла аутентификация клиента или запрос недействителен, сервер авторизации возвращает отклик с ошибкой, как указано в параграфе 5.2.

5.1. Отклик об успехе

Сервер авторизации выдаёт маркер доступа и (необязательно) маркер обновления и готовит ответ, добавляя указанные ниже параметры в тело отклика HTTP с кодом 200 (OK).

access_token

Обязательно. Маркер доступа, выданный сервером авторизации.

token_type

Обязательно. Тип выданного маркера (см. параграф 7.1). Регистр символов не учитывается.

expires_in

Рекомендуется. Срок действия маркера в секундах. Например, значение 3600 указывает, что действие маркера прекратится через 1 час с момента генерации отклика. Если параметр не указывается, серверу авторизации следует задавать срок действия иным способом или приводить принятый по умолчанию срок в документации.

refresh_token

Необязательно. Маркер обновления, который может применяться для получения нового маркера доступа с использованием той же авторизации, как описано в разделе 6.

scope

state

Обязательно, если в запросе авторизации был параметр state. Значение берётся из запроса клиента.

Параметры включаются в тело отклика HTTP с использованием типа носителя application/json, как указано в [RFC4627]. Параметры последовательно помещаются в структуру JSON²⁰ путём добавления каждого на верхний уровень структуры. Имена параметров и значения строк включаются в виде строк JSON, численные значения — как числа JSON. Порядок параметров не имеет значения и может меняться.

Сервер авторизации должен включать поле заголовка HTTP Cache-Control [RFC2616] со значением no-store во все отклики с маркером, учётными данными или иными конфиденциальными сведениями, а также поле заголовка Pragma [RFC2616] со значением no-cache.

Пример отклика приведён ниже.

     HTTP/1.1 200 OK
     Content-Type: application/json¹
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

5.2. Отклик об ошибке

Сервер авторизации отвечает с кодом статуса HTTP 400 (Bad Request), если не задано иное, и включает в отклик указанные ниже параметры.

error

Обязательно. Одна строка ASCII [USASCII] с кодом ошибки из числа приведённых ниже.

invalid_request

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

invalid_client

Клиент не прошёл проверку подлинности (например, неизвестен, аутентификация не включена или метод проверки не поддерживается). Сервер авторизации может возвращать код HTTP 401 (Unauthorized) для указания поддерживаемых схем HTTP-аутентификации. При попытке клиента аутентифицироваться через поле заголовка Authorization сервер авторизации должен возвращать код статуса HTTP 401 (Unauthorized) и включать в заголовок отклика поле WWW-Authenticate, соответствующее использованной клиентом схеме.

invalid_grant

Представленное разрешение (например, код авторизации, учётные данные владельца) или маркер обновления недействительны, устарели, отозваны, не соответствуют URI перенаправления в запросе авторизации или выданы другому клиенту.

unauthorized_client

У клиента нет полномочий использовать этот тип разрешения.

unsupported_grant_type

Тип разрешения не поддерживается сервером авторизации.

invalid_scope

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

server_error²¹

temporarily_unavailable

В значение параметра error недопустимо включать символы, отличные от %x20-21 / %x23-5B / %x5D-7E.

error_description

error_uri

Параметры включаются в тело отклика HTTP с использованием типа носителя application/json, как указано в [RFC4627]. Параметры последовательно помещаются в структуру JSON путём добавления каждого на верхний уровень структуры. Имена параметров и значения строк включаются в виде строк JSON, численные значения — как числа JSON. Порядок параметров не имеет значения и может меняться. Пример отклика приведён ниже.

     HTTP/1.1 400 Bad Request
     Content-Type: application/json²²
     Cache-Control: no-store
     Pragma: no-cache

     {
       "error":"invalid_request"
     }

6. Обновление маркера доступа

Если сервер авторизации выдал клиенту маркер обновления, клиент может запросить обновление у конечной точки маркеров, добавляя указанные ниже параметры в тело HTTP-запроса в формате application/x-www-form-urlencoded (Приложение B) с кодировкой символов UTF-8.

grant_type

Обязательно и должно иметь значение refresh_token.

refresh_token

Обязательно. Маркер обновления, выданный клиенту

scope

Необязательно. Область доступа для запроса, как указано в параграфе 3.3. В запрашиваемую область недопустимо включать какую-либо область, не разрешённую изначально владельцем ресурса, а по умолчанию принимается исходно выделенная владельцем область доступа.

Поскольку маркеры обновления обычно являются долговременными свидетельствами, используемыми для получения новых маркеров доступа, они привязываются к получившему маркер клиенту. Если клиент является конфиденциальными или ему были выданы учётные данные (или иные средства аутентификации), клиент должен подтвердить свою подлинность серверу авторизации, как описано в параграфе 3.2.1.

Например, клиент может передать запрос HTTP с защитой на транспортом уровне:

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

Сервер авторизации должен:

требовать проверки подлинности для всех конфиденциальных клиентов и клиентов, предоставивших свои учётные данные (или иные данные для аутентификации);
аутентифицировать клиента, если включена аутентификация, и убедиться, что маркер обновления выдан ему;
проверить маркер обновления.

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

7. Доступ к защищённым ресурсам

Клиент получает доступ к защищённым ресурсам, предъявив серверу ресурсов маркер доступа. Сервер ресурсов должен проверить маркер и убедиться, что срок действия не истёк и область действия охватывает запрошенное. Методы проверки маркера доступа (и сообщения об ошибках) выходят за рамки этого документа, но обычно включают взаимодействие или согласование между серверами ресурсов и авторизации.

Метод использования клиентом маркера доступа для аутентификации на сервере ресурсов зависит от типа маркера доступа, выданного сервером авторизации. Обычно это включает использование поля заголовка запроса HTTP Authorization [RFC2617] со схемой проверки подлинности, заданной спецификацией используемого типа маркера (например, [RFC6750]).

7.1. Типы маркеров доступа

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

Например, тип bearer, определённый в [RFC6750], применяется путём простого включения строки маркера в запрос.

     GET /resource/1 HTTP/1.1
     Host: example.com
     Authorization: Bearer mF_9.B5f-4.1JqM

Тип mac, заданный в [Oauth-HTTP-MAC], применяется путём указания в дополнение к маркеру кода MAC²³, который служит подписью некоторых компонентов запроса HTTP

     GET /resource/1 HTTP/1.1
     Host: example.com
     Authorization: MAC id="h480djs93hd8",
                        nonce="274312:dj83hs9s",
                        mac="kDZvddkndxvhGRXZhvuDjEWhGeE="

Эти примеры приведены лишь для иллюстрации. Разработчикам рекомендуется ознакомиться со спецификациями [RFC6750] и [Oauth-HTTP-MAC] до начала работы.

Каждое определение типа маркера задаёт дополнительные атрибуты (если они есть), передаваемые клиентом вместе с параметром отклика access_token, а также метод аутентификации HTTP, используемый для включения маркера доступа при запросе к защищаемому ресурсу.

7.2. Отклик об ошибке

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

Новым схемам проверки подлинности, создаваемым, прежде всего, для аутентификации маркеров Oauth, следует задавать механизмы предоставления клиенту кодов ошибок, включаемых в созданный этой спецификацией реестр. Такие схемы могут ограничивать набор действительных кодов ошибок частью зарегистрированных значений. Если код возвращается с использованием именованного параметра, его следует называть error.

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

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

8. Расширяемость

8.1. Задание типа маркера доступа

Типы маркеров доступа могут определяться двумя способами: включением в реестр Access Token Types (по процедуре из параграфа 11.1) или использованием уникального абсолютного URI в качестве имени.

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

Прочие типы должны регистрироваться. Имена типов должны соответствовать ABNF type-name. Если определение типа включает новую схему аутентификации HTTP, имя следует выбирать идентичным имени схемы аутентификации HTTP, как указано в [RFC2617]. Тип маркера example зарегистрирован для использования в примерах.

     type-name  = 1*name-char
     name-char  = "-" / "." / "_" / DIGIT / ALPHA

8.2. Задание параметров новой конечной точки

Новые параметры запросов и откликов для использования с конечными точками авторизации или маркеров определяются и регистрируются в реестре OAuth Parameters по процедуре, описанной в параграфе 11.2. Имена параметров должны соответствовать ABNF param-name, а синтаксис значения параметров должен быть чётко задан (например, с помощью ABNF или ссылкой на синтаксис имеющегося параметра).

     param-name  = 1*name-char
     name-char   = "-" / "." / "_" / DIGIT / ALPHA

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

8.3. Задание новых типов разрешения (Authorization Grant)

Новые типы разрешений (authorization grant) могут определяться уникальными абсолютными URI для использования с параметром grant_type. Если расширенному разрешению нужны дополнительные параметры конечной точки маркера, они должны регистрироваться в реестре OAuth Parameters, как описано в параграфе 11.2.

8.4. Задание новых типов откликов конечной точки авторизации

Новые типы откликов для использования с конечными точками авторизации регистрируются в реестре Authorization Endpoint Response Types (см. параграф 11.3). Имена типов должны соответствовать ABNF response-type.

     response-type  = response-name *( SP response-name )
     response-name  = 1*response-char
     response-char  = "_" / DIGIT / ALPHA

Если тип отклика содержит один или несколько символов пробела (%x20), он сравнивается со списком разделённых пробелами значений без учёта их порядка. Зарегистрировать можно лишь один порядок, охватывающий все варианты того же набора значений. Например, тип отклика token code не определён в этой спецификации, однако расширение может определить и зарегистрировать такой тип. После этого не может быть зарегистрирована комбинация code token, но оба варианта могут применяться для обозначения одного типа отклика.

8.5. Задание дополнительных кодов ошибок

Если расширения протокола (типы маркеров доступа, параметры расширения или типы разрешения) требуют дополнительных кодов для откликов об ошибке предоставления кода авторизации (параграф 4.1.2.1), неявного разрешения (параграф 4.2.2.1), маркера (параграф 5.2) или доступа к ресурсу (параграф 7.2), эти коды можно задать.

Коды ошибок расширений должны регистрироваться (параграф 11.4), если расширение, с которым они используются, является зарегистрированным типом маркера доступа, параметром конечной точки или расширенным типом разрешения. Можно регистрировать и коды, применяемые с незарегистрированными расширениями.

Коды ошибок должны соответствовать ABNF error и для них следует по возможности задавать префикс в виде идентифицирующего имени. Например, для ошибки, указывающей недействительное значение параметра example, следует использовать имя example_invalid.

     error      = 1*error-char
     error-char = %x20-21 / %x23-5B / %x5D-7E

9. Естественные приложения

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

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

Внешний агент пользователя — естественное приложение может получать отклик от сервера авторизации, используя URI перенаправления со схемой, зарегистрированной в операционной системе, для вызова клиента в качестве обработчика, копирования и вставки учётных данных, запуска локального web-сервера, установки расширения в агент пользователя или предоставления URI перенаправления, указывающего контролируемый клиентом ресурс на сервере, который делает отклик доступным для приложения.
Встроенный агент пользователя — естественное приложение получает отклик, напрямую взаимодействуя со агентом пользователя за счёт мониторинга смены состояний в процессе загрузки ресурса или доступа к хранилищу cookie пользовательского агента.

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

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

При выборе между неявным разрешением и кодом авторизации следует учитывать указанное ниже.

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

10. Вопросы безопасности

Безопасность гибкой и расширяемой платформы Oauth зависит от множества факторов. В последующих параграфах приведены рекомендации для разработчиков по обеспечению безопасности для трёх профилей клиентов, указанных в параграфе 2.1: web-приложений, приложений на основе агента пользователя и естественных приложений.

Полная модель и анализ безопасности Oauth, а также основы устройства протокола даны в [OAuth-THREATMODEL].

10.1. Проверка подлинности клиента

Сервер авторизации организует учётные данные web-клиентов для целей их аутентификации. Серверам авторизации рекомендуется использовать более надёжные средства проверки подлинности клиентов, нежели просто пароль. Web-клиенты должны обеспечивать конфиденциальность своих паролей и учётных данных.

Серверу авторизации недопустимо выдавать пароли и другие учётные данные естественным приложениям и клиентам на основе пользовательских агентов для целей аутентификации клиента. Сервер может выдавать пароль и другие учётные данные клиентам для конкретной установки естественного приложения клиента на конкретном устройстве.

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

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

10.2. Подмена клиента

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

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

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

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

10.3. Маркеры доступа

Учётные данные маркера доступа (и другие его конфиденциальные атрибуты) должны оставаться секретными при передаче и хранении, а раскрывать их можно только серверу авторизации, серверу ресурсов, для которого маркер действует, и клиенту, которому маркер выдан. Учётные данные маркеров доступа должны передаваться только по протоколу TLS (параграф 1.6) с аутентификацией сервера в соответствии с [RFC2818].

При использовании неявных разрешений маркер доступа передаётся во фрагменте URI, который может раскрываться неуполномоченным сторонам.

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

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

Эта спецификация не задаёт для сервера ресурсов методов проверки того, что представленный данным клиентом маркер доступа выдан сервером авторизации именно этому клиенту.

10.4. Маркеры обновления

Серверы авторизации могут выдавать маркеры обновления web-клиентам и клиентам естественных приложений.

Маркеры обновления должны оставаться секретными при передаче и хранении, а раскрывать их можно только серверу авторизации и клиенту, которому маркер выдан. Сервер авторизации должен поддерживать привязку маркера обновления к клиенту, которому маркер выдан. Маркеры обновления должны передаваться только по протоколу TLS (параграф 1.6) с аутентификацией сервера в соответствии с [RFC2818].

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

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

10.5. Коды авторизации

Коды авторизации следует передавать по защищённому каналу, а клиенту следует требовать использования TLS в его URI перенаправления, если URI указывает сетевой ресурс. Поскольку коды авторизации передаются через перенаправления пользовательского агента, они потенциально могут быть раскрыты через историю пользовательского агента и заголовки HTTP referrer.

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

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

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

10.6. Манипуляции с URI перенаправления кода авторизации

При запросе авторизации с помощью типа «код авторизации» клиент может задать URI перенаправление параметром redirect_uri. Если злоумышленник способен менять URI перенаправления, он сможет заставить сервер авторизации направить пользовательский агент владельца ресурса с кодом авторизации на контролируемый атакующим URI. Злоумышленник может создать учётную запись у легитимного клиента и инициировать поток авторизации. Когда пользовательский агент злоумышленника передаёт серверу авторизации запрос на получение доступа, атакующий перехватывает URI авторизации, представленный легитимным клиентом, и меняет его на контролируемый URI. Затем злоумышленник заставляет жертву перейти по изменённой ссылке для авторизации доступа к легитимному клиенту. После обращения к серверу авторизации жертве отправляется обычный действительный запрос от имени легитимного и доверенного клиента и жертва авторизует этот запрос. Затем жертва направляется в контролируемую атакующим конечную точку с кодом авторизации. Злоумышленник завершает процесс авторизации путём передачи кода авторизации клиенту с использованием исходного URI перенаправления, предоставленного клиентом. Клиент обменивает код авторизации на маркер доступа и связывает его с учётной записью злоумышленника, который теперь может получить доступ к защищённым ресурсам, авторизованным жертвой (через клиент).

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

10.7. Пароль владельца ресурса

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

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

Серверу авторизации следует минимизировать применение этого типа и по возможности использовать другие типы.

10.8. Конфиденциальность запроса

Маркеры доступа и обновления, пароли владельцев ресурсов и учётные данные клиентов недопустимо передавать в открытом виде. Коды авторизации не следует передавать в открытом виде.

В параметры state и scope не следует включать деликатные (sensitive) сведения о клиенте или владельце ресурса в открытом виде, поскольку эти параметры могут передаваться и храниться без защиты.

10.9. Обеспечение аутентичности конечных точек

Для предотвращения MITM²⁴-атак сервер авторизации должен требовать использования TLS при аутентификации сервера (см. [RFC2818]) для всех запросов, передаваемых конечным точкам авторизации и маркеров. Клиент должен проверять сертификат TLS сервера авторизации, как указано в [RFC6125], в соответствии со своими требованиями к проверке подлинности сервера.

10.10. Атаки с подбором учётных данных

Сервер авторизации должен предотвращать попытки атакующих подобрать маркеры доступа, коды авторизации, маркеры обновления, пароли владельцев ресурсов и учётные данные пользователей. Вероятность угадывания атакующим генерируемых маркеров (и других учётных данных, не предназначенных для конечного пользователя) должна быть не выше 2^-128 и следует пытаться обеспечить значение не выше 2^-160.

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

10.11. Фишинговые атаки

Широкое внедрение этого и похожих протоколов может привести к тому, что конечные пользователи привыкнут к практике перенаправления на web-сайты, где их попросят ввести пароль. Если конечные пользователи не будут внимательно проверять подлинность этих сайтов перед вводом своих учётных данных, злоумышленники смогут воспользоваться такой практикой для кражи паролей владельцев ресурсов.

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

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

10.12. Кросс-сайтовая подмена запросов

При кросс-сайтовой подмене запросов (Cross-site request forgery или CSRF) атакующий заставляет пользовательский агент конечного пользователя-жертвы перейти по вредоносному URI (например, враждебная ссылка, изображение или перенаправление) на доверенный сервер (обычно с помощью действительных сеансовых cookie).

Атака CSRF на клиентский URI перенаправления позволяет злоумышленнику внедрить свой код авторизации или маркер доступа, что может привести использовавшего его клиента на защищённый ресурс атакующего, вместо желаемого ресурса (например, для сохранения сведений о банковском счёте на контролируемом атакующим ресурсе).

Клиент должен реализовать защиту от CSRF для своего URI перенаправления. Обычно это реализуется за счёт включения в URI, передаваемые в конечную точку, значения, связывающего запрос с аутентифицированным состоянием пользовательского агента (например, хэш сеансового cookie, использованного для аутентификации агента пользователя). Клиенту следует использовать параметр запроса state для доставки этого значения серверу авторизации при отправке запроса на авторизацию.

После получения авторизации от конечного пользователя сервер авторизации перенаправляет агент конечного пользователя обратно к клиенту с требуемым значением привязки в параметре state. Значение привязки позволяет клиенту проверить запрос, сопоставляя значение привязки с аутентифицированным состоянием пользовательского агента. Значение привязки, служащее защитой от CSRF, должно быть непредсказуемым (см. параграф 10.10), а аутентифицированное состояние пользовательского агента (например, сеансовые cookie, локальное хранилище HTML5) должно быть доступно только клиенту и пользовательскому агенту (т. е., защищено по тем же правилам).

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

10.13. Перехват действий (Clickjacking)

В атаках с перехватом действия злоумышленник регистрирует легитимного клиента, а затем создаёт вредоносный сайт, на котором загружается web-страница конечной точки авторизации сервера авторизации в прозрачном iframe, наложенном на тщательно подготовленный набор кнопок, размещённых непосредственно под важными кнопками на странице авторизации. Когда конечный пользователь нажимает (click) видимую кнопку, на деле он жмёт невидимую кнопку на странице авторизации (например, кнопку Authorize). Это позволяет злоумышленнику обманом заставить владельца ресурса предоставить его клиенту доступ без ведома конечного пользователя.

Для предотвращения таких атак естественным приложениям следует при запросе авторизации конечного пользователя применять внешние браузеры вместо встроенного в приложение. Для большинства новых браузеров сервер авторизации может предотвратить использование iframe с помощью (нестандартного) заголовка x-frame-options. Этот заголовок может иметь два значения (deny и sameorigin), которые будут блокировать все фреймы или фреймы сайтов с другим источником. Для более старых браузеров можно применять методы перебора фреймов JavaScript, но они работают не во всех браузерах.

10.14. Внедрение кода и проверка входных данных

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

Сервер авторизации и клиент должны проверять (и подтверждать, если возможно) любое полученное значение, в частности, значения параметров state и redirect_uri.

10.15. Открытые редиректоры

Сервер авторизации, конечная точка авторизации и конечная точка перенаправления клиента могут быть настроены некорректно и работать как открытые редиректоры. Такой редиректор использует параметр для автоматического перенаправления агента пользователя в указанное место без какой-либо проверки.

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

10.16. Злоупотребление маркером доступа для подмены в неявном потоке

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

В неявном потоке (response_type=token) атакующему легко подменить маркер в отклике от сервера авторизации, поместив в отклик выданный ему ранее маркер доступа. Взаимодействующие с естественными приложениями серверы, которые полагаются на маркер доступа в канале возврата для идентификации пользователя клиента, могут быть скомпрометированы аналогичным способом злоумышленником, создавшим компрометирующее приложение, которое будет внедрять украденные маркеры доступа. Публичные клиенты, считающие, что действительный маркер доступа к ресурсу может предоставить лишь владелец этого ресурса, уязвимы к таким атакам.

Атаки этого типа могут раскрывать атакующему (вредоносный клиент) сведения о владельце ресурса на легитимном клиенте, что позволит злоумышленнику выполнить на легитимном клиенте операции доступа с полномочиями владельца ресурса, изначально предоставившего маркер доступа или код авторизации.

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

11. Взаимодействие с IANA

11.1. Реестр OAuth Access Token Types

Эта спецификация организует реестр OAuth Access Token Types.

Типы маркеров доступа регистрируются по процедуре Specification Required [RFC5226] после двухнедельного обсуждения в почтовой конференции oauth-ext-review@ietf.org по рекомендации одного или нескольких назначенных экспертов. Чтобы выделить значения до публикации документа, назначенные эксперты могут одобрить регистрацию, как только убедятся в том, что спецификация будет опубликована.

Регистрационные запросы должны направляться по адресу oauth-ext-review@ietf.org для рецензирования и комментариев с указанием соответствующего поля subject (например, Request for access token type: example).

В период обзора назначенные эксперты одобряют или отклоняют запрос на регистрацию, сообщая о своём решении в почтовой конференции и уведомляя IANA. Отказ следует сопровождать объяснением и, по возможности, предложениями по исправлению недочётов.

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

11.1.1. Шаблон регистрации

Type name

Регистрируемое имя (например, example).

Additional Token Endpoint Response Parameters

Дополнительные параметры отклика, требуемые вместе с access_token. Новые параметры должны регистрироваться в реестре OAuth Parameters, как указано в параграфе 11.2.

HTTP Authentication Scheme(s)

Имена схем аутентификации HTTP (при наличии), используемых для аутентификации запросов к защищённым ресурсам с использованием этого типа маркеров доступа.

Change controller

Для RFC серии Standards Track — это IETF, для прочих — имя ответственного лица. Могут также включаться дополнительные сведения (например, почтовый адрес, адрес электронной почты, URI домашней страницы).

Specification document(s)

Ссылка на документы, задающие код ошибки (предпочтительно URI, по которому можно получить копию документа). Можно также указывать соответствующий раздел документа, но это не требуется.

11.2. Реестр OAuth Parameters

Эта спецификация организует реестр OAuth Parameters.

Дополнительные параметры для включения в запрос конечной точки авторизации, а также запрос и отклик конечной точки маркера, регистрируются по процедуре Specification Required [RFC5226] после двухнедельного обсуждения в почтовой конференции oauth-ext-review@ietf.org по рекомендации одного или нескольких назначенных экспертов. Чтобы выделить значения до публикации документа, назначенные эксперты могут одобрить регистрацию, как только убедятся в том, что спецификация будет опубликована.

11.2.1. Шаблон регистрации

Parameter name

Регистрируемое имя (например, example).

Parameter usage location

Места использования параметра (запрос и отклик авторизации, запрос маркера и отклик на него).

Change controller

Specification document(s)

11.2.2. Исходное содержимое реестра

Parameter name: client_id
Parameter usage location: authorization request, token request
Change controller: IETF
Specification document(s): RFC 6749

Parameter name: client_secret
Parameter usage location: token request
Change controller: IETF
Specification document(s): RFC 6749

Parameter name: response_type
Parameter usage location: authorization request
Change controller: IETF
Specification document(s): RFC 6749

Parameter name: redirect_uri
Parameter usage location: authorization request, token request
Change controller: IETF
Specification document(s): RFC 6749

Parameter name: scope
Parameter usage location: authorization request, authorization response, token request, token response
Change controller: IETF
Specification document(s): RFC 6749

Parameter name: state
Parameter usage location: authorization request, authorization response
Change controller: IETF
Specification document(s): RFC 6749

Parameter name: code
Parameter usage location: authorization response, token request
Change controller: IETF
Specification document(s): RFC 6749

Parameter name: error²⁵
Parameter usage location: authorization response, token request
Change controller: IETF
Specification document(s): RFC 6749
Parameter name: error_description
Parameter usage location: authorization response, token response
Change controller: IETF
Specification document(s): RFC 6749

Parameter name: error_uri
Parameter usage location: authorization response, token response
Change controller: IETF
Specification document(s): RFC 6749

Parameter name: grant_type
Parameter usage location: token request
Change controller: IETF
Specification document(s): RFC 6749

Parameter name: access_token
Parameter usage location: authorization response, token response
Change controller: IETF
Specification document(s): RFC 6749

Parameter name: token_type
Parameter usage location: authorization response, token response
Change controller: IETF
Specification document(s): RFC 6749

Parameter name: expires_in
Parameter usage location: authorization response, token response
Change controller: IETF
Specification document(s): RFC 6749

Parameter name: username
Parameter usage location: token request
Change controller: IETF
Specification document(s): RFC 6749

Parameter name: password
Parameter usage location: token request
Change controller: IETF
Specification document(s): RFC 6749

Parameter name: refresh_token
Parameter usage location: token request, token response
Change controller: IETF
Specification document(s): RFC 6749

11.3. Реестр OAuth Authorization Endpoint Response Types

Эта спецификация организует реестр OAuth Authorization Endpoint Response Types.

Дополнительные типы откликов, применяемые с конечными точками авторизации, регистрируются по процедуре Specification Required [RFC5226] после двухнедельного обсуждения в почтовой конференции oauth-ext-review@ietf.org по рекомендации одного или нескольких назначенных экспертов. Чтобы выделить значения до публикации документа, назначенные эксперты могут одобрить регистрацию, как только убедятся в том, что спецификация будет опубликована.

11.3.1. Шаблон регистрации

Response type name

Регистрируемое имя (например, example).

Change controller

Specification document(s)

11.3.2. Исходное содержимое реестра

Response type name: code
Change controller: IETF
Specification document(s): RFC 6749

Response type name: token
Change controller: IETF
Specification document(s): RFC 6749

11.4. Реестр OAuth Extensions Error

Эта спецификация организует реестр OAuth Extensions Error.

Дополнительные коды ошибок, применяемые с расширениями протокола (например, типами разрешения, типами маркеров доступа, параметрами расширений), регистрируются по процедуре Specification Required [RFC5226] после двухнедельного обсуждения в почтовой конференции oauth-ext-review@ietf.org по рекомендации одного или нескольких назначенных экспертов. Чтобы выделить значения до публикации документа, назначенные эксперты могут одобрить регистрацию, как только убедятся в том, что спецификация будет опубликована.

11.4.1. Шаблон регистрации

Error name

Регистрируемое имя (например, example). В имена недопустимо включать символы, отличные от %x20-21 / %x23-5B / %x5D-7E.

Error usage location

Места, где ошибка может применяться, например, отклик об ошибке разрешения по коду авторизации (параграф 4.1.2.1), отклик об ошибке при неявном разрешении (параграф 4.2.2.1), отклик об ошибке маркера (параграф 5.2), отклик при ошибке доступа к ресурсу (параграф 7.2).

Related protocol extension

Имя расширенного типа, типа access token или параметра расширения, с которым применяется код ошибки.

Change controller

Specification document(s)

11.4.2. Исходное содержимое реестра²⁶

Error name: invalid_request
Error usage location: authorization code grant error response, implicit grant error response, token error response
Related protocol extension: authorization code grant, implicit grant, any access token type
Change controller: IETF
Specification document(s): RFC 6749

Error name: unauthorized_client
Error usage location: authorization code grant error response, implicit grant error response, token error response
Related protocol extension: authorization code grant, implicit grant, any access token type
Change controller: IETF
Specification document(s): RFC 6749

Error name: access_denied
Error usage location: authorization code grant error response, implicit grant error response
Related protocol extension: authorization code grant, implicit grant
Change controller: IETF
Specification document(s): RFC 6749

Error name: unsupported_response_type
Error usage location: authorization code grant error response, implicit grant error response
Related protocol extension: authorization code grant, implicit grant
Change controller: IETF
Specification document(s): RFC 6749

Error name: invalid_scope
Error usage location: authorization code grant error response, implicit grant error response, token error response
Related protocol extension: authorization code grant, implicit grant, any access token type
Change controller: IETF
Specification document(s): RFC 6749

Error name: server_error
Error usage location: authorization code grant error response, implicit grant error response
Related protocol extension: authorization code grant, implicit grant
Change controller: IETF
Specification document(s): RFC 6749

Error name: temporarily_unavailable
Error usage location: authorization code grant error response, implicit grant error response
Related protocol extension: authorization code grant, implicit granto Change controller: IETF
Specification document(s): RFC 6749

Error name: invalid_client
Error usage location: token error response
Related protocol extension: any access token type
Change controller: IETF
Specification document(s): RFC 6749

Error name: invalid_grant
Error usage location: token error response
Related protocol extension: any access token type
Change controller: IETF
Specification document(s): RFC 6749

Error name: unsupported_grant_type
Error usage location: token error response
Related protocol extension: any access token type
Change controller: IETF
Specification document(s): RFC 6749

12. Литература

12.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2246] Dierks, T. and C. Allen, «The TLS Protocol Version 1.0», RFC 2246, January 1999.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.

[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, «HTTP Authentication: Basic and Digest Access Authentication», RFC 2617, June 1999.

[RFC2818] Rescorla, E., «HTTP Over TLS», RFC 2818, May 2000.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, November 2003.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.

[RFC4627] Crockford, D., «The application/json Media Type for JavaScript Object Notation (JSON)», RFC 4627, July 2006.

[RFC4949] Shirey, R., «Internet Security Glossary, Version 2», RFC 4949, August 2007.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5234] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, August 2008.

[RFC6125] Saint-Andre, P. and J. Hodges, «Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)», RFC 6125, March 2011.

[USASCII] American National Standards Institute, «Coded Character Set — 7-bit American Standard Code for Information Interchange», ANSI X3.4, 1986.

[W3C.REC-html401-19991224] Raggett, D., Le Hors, A., and I. Jacobs, «HTML 4.01 Specification», World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>.

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, «Extensible Markup Language (XML) 1.0 (Fifth Edition)», World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.

12.2. Дополнительная литература

[Oauth-HTTP-MAC] Hammer-Lahav, E., Ed., «HTTP Authentication: MAC Access Authentication», Work in Progress, February 2012.

[Oauth-SAML2] Campbell, B. and C. Mortimore, «SAML 2.0 Bearer Assertion Profiles for OAuth 2.0», Work in Progress²⁷, September 2012.

[Oauth-THREATMODEL] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, «OAuth 2.0 Threat Model and Security Considerations», Work in Progress²⁸, October 2012.

[Oauth-WRAP] Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, «Oauth Web Resource Authorization Profiles», Work in Progress, January 2010.

[RFC5849] Hammer-Lahav, E., «The OAuth 1.0 Protocol», RFC 5849, April 2010.

[RFC6750] Jones, M. and D. Hardt, «The OAuth 2.0 Authorization Framework: Bearer Token Usage», RFC 6750, October 2012.

Приложение A. Синтаксис ABNF

В этом приложении описан синтаксис ABNF для заданных этой спецификацией элементов с использованием нотации [RFC5234]. Представление ABNF ниже использует коды Unicode [W3C.REC-xml-20081126], а символы обычно кодируются в UTF-8. Элементы указаны в порядке их определения в спецификации.

В некоторых элементах применяется определение URI-reference из [RFC3986]. В части элементов применяются базовые определения, приведённые ниже:

     VSCHAR     = %x20-7E
     NQCHAR     = %x21 / %x23-5B / %x5D-7E
     NQSCHAR    = %x20-21 / %x23-5B / %x5D-7E
     UNICODECHARNOCRLF = %x09 /%x20-7E / %x80-D7FF /
                         %xE000-FFFD / %x10000-10FFFF

Определение UNICODECHARNOCRLF основано на определении Char в параграфе 2.2 [W3C.REC-xml-20081126], но не включает символы возврата каретки (Carriage Return или CR) и перевода строки (Linefeed или LF).

A.1. Синтаксис client_id

Элемент client_id определён в параграфе 2.3.1:

     client-id     = *VSCHAR

A.2. Синтаксис client_secret

Элемент client_secret определён в параграфе 2.3.1:

     client-secret = *VSCHAR

A.3. Синтаксис response_type

Элемент response_type определён в параграфах 3.1.1 and 8.4:

     response-type = response-name *( SP response-name )
     response-name = 1*response-char
     response-char = "_" / DIGIT / ALPHA

A.4. Синтаксис scope

Элемент scope определён в параграфе 3.3:

     scope       = scope-token *( SP scope-token )
     scope-token = 1*NQCHAR

A.5. Синтаксис state

Элемент state определён в параграфах 4.1.1, 4.1.2, 4.1.2.1, 4.2.1, 4.2.2, 4.2.2.1:

     state      = 1*VSCHAR

A.6. Синтаксис redirect_uri

Элемент redirect_uri определён в параграфах 4.1.1, 4.1.3, 4.2.1:

     redirect-uri      = URI-reference

A.7. Синтаксис error

Элемент error определён в параграфах 4.1.2.1, 4.2.2.1, 5.2, 7.2, 8.5:

     error             = 1*NQSCHAR

A.8. Синтаксис error_description

Элемент error_description определён в параграфах 4.1.2.1, 4.2.2.1, 5.2, 7.2:

     error-description = 1*NQSCHAR

A.9. Синтаксис error_uri

Элемент error_uri определён в параграфах 4.1.2.1, 4.2.2.1, 5.2, 7.2:

     error-uri         = URI-reference

A.10. Синтаксис grant_type

Элемент grant_type определён в параграфах 4.1.3, 4.3.2, 4.4.2, 4.5, 6:

     grant-type = grant-name / URI-reference
     grant-name = 1*name-char
     name-char  = "-" / "." / "_" / DIGIT / ALPHA

A.11. Синтаксис code

Элемент code определён в параграфе 4.1.3:

     code       = 1*VSCHAR

A.12. Синтаксис access_token

Элемент access_token определён в параграфах 4.2.2 и 5.1:

     access-token = 1*VSCHAR

A.13. Синтаксис token_type

Элемент token_type определён в параграфах 4.2.2, 5.1, 8.1:

     token-type = type-name / URI-reference
     type-name  = 1*name-char
     name-char  = "-" / "." / "_" / DIGIT / ALPHA

A.14. Синтаксис expires_in

Элемент expires_in определён в параграфах 4.2.2 и 5.1:

     expires-in = 1*DIGIT

A.15. Синтаксис username

Элемент username определён в параграфе 4.3.2:

     username = *UNICODECHARNOCRLF

A.16. Синтаксис password

Элемент password определён в параграфе 4.3.2:

     password = *UNICODECHARNOCRLF

A.17. Синтаксис refresh_token

Элемент refresh_token определён в параграфах 5.1 и 6:

     refresh-token = 1*VSCHAR

A.18. Синтаксис параметров конечной точки

Синтаксис параметров новой конечной точки определён в параграфе 8.2:

     param-name = 1*name-char
     name-char  = "-" / "." / "_" / DIGIT / ALPHA

Приложение B. Носитель application/x-www-form-urlencoded

На момент публикации этого документа тип носителя application/x-www-form-urlencoded был определён в параграфе 17.13.4 [W3C.REC-html401-19991224], но не зарегистрирован в реестре IANA MIME Media Types. Кроме того, определение было неполным, поскольку не учитывало символы, отличные от US-ASCII.

Для устранения этого недостатка при генерации содержимого с использованием данного типа носителя имена и значения должны кодироваться с использованием схемы UTF-8 [RFC3629], а полученная цепочка октетов должна преобразовываться по правилам экранирования, заданным в [W3C.REC-html401-19991224].

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

Например, значение из 6 кодов Unicode

   (1) U+0020 (SPACE), (2) U+0025 (PERCENT SIGN),
   (3) U+0026 (AMPERSAND), (4) U+002B (PLUS SIGN),
   (5) U+00A3 (POUND SIGN), and (6) U+20AC (EURO SIGN)

будет кодироваться в строку октетов (шестнадцатеричное представление):

     20 25 26 2B C2 A3 E2 82 AC

и указываться в содержимом как:

     +%25%26%2B%C2%A3%E2%82%AC

Приложение C. Благодарности

Спецификацию протокола OAuth 2.0 редактировал David Recordon на основе двух предшествующих спецификаций — OAuth 1.0 [RFC5849] и OAuth WRAP (OAuth Web Resource Authorization Profiles) [OAuth-WRAP]. Затем Eran Hammer отредактировал многочисленные черновые варианты, которые стали основой этого RFC. Раздел «Вопросы безопасности» был подготовлен Torsten Lodderstedt, Mark McGloin, Phil Hunt, Anthony Nadalin и John Bradley. Приложение по использованию типа носителя application/x-www-form-urlencoded подготовлено Julian Reschke, а приложение с ABNF — Michael B. Jones.

Редактором спецификации OAuth 1.0 был Eran Hammer, авторами — Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M. Conlan, Blaine Cook, Leah Culver, Breno de Medeiros, Brian Eaton, Kellan Elliott-McCrea, Larry Halff, Eran Hammer, Ben Laurie, Chris Messina, John Panzer, Sam Quigley, David Recordon, Eran Sandler, Jonathan Sergent, Todd Sieling, Brian Slesinsky, Andy Smith.

Редактором спецификации OAuth WRAP был Dick Hardt, авторами — Brian Eaton, Yaron Y. Goland, Dick Hardt, Allen Tom.

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

Michael Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, Aiden Bell, John Bradley, Marcos Caceres, Brian Campbell, Scott Cantor, Blaine Cook, Roger Crew, Leah Culver, Bill de hOra, Andre DeMarre, Brian Eaton, Wesley Eddy, Wolter Eldering, Brian Ellin, Igor Faynberg, George Fletcher, Tim Freeman, Luca Frosini, Evan Gilbert, Yaron Y. Goland, Brent Goldman, Kristoffer Gronowski, Eran Hammer, Dick Hardt, Justin Hart, Craig Heath, Phil Hunt, Michael B. Jones, Terry Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara, Rasmus Lerdorf, Torsten Lodderstedt, Hui-Lan Lu, Casey Lucas, Paul Madsen, Alastair Mair, Eve Maler, James Manger, Mark McGloin, Laurence Miao, William Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Luke Shepard, Vlad Skvortsov, Justin Smith, Haibin Song, Niv Steingarten, Christian Stuebner, Jeremy Suriel, Paul Tarjan, Christopher Thomas, Henry S. Thompson, Allen Tom, Franklin Tse, Nick Walker, Shane Weeden, Skylar Woodward.

Этот документ был создан под руководством Blaine Cook, Peter Saint-Andre, Hannes Tschofenig, Barry Leiba и Derek Atkins. Директорами направлений были Lisa Dusseault, Peter Saint-Andre и Stephen Farrell.

Адрес автора

Dick Hardt (editor)

Microsoft

EMail: dick.hardt@gmail.com

URI: http://dickhardt.org/

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

3В оригинале ошибочно сказано о смене пароля третьей стороны. Прим. перев. См. https://www.rfc-editor.org/errata/eid3446

4Augmented Backus-Naur Form — расширенная форма Бэкуса-Наура.

5В исходном документе это предложение содержит ошибки. Прим. перев. См. https://www.rfc-editor.org/errata/eid5234

6В https://www.rfc-editor.org/errata/eid6017 предложено указать в первом предложении [RFC7617], а второе — исключить. Прим. перев.

7Это предложение отсутствует в исходном документе. Прим. перев. См. https://www.rfc-editor.org/errata/eid4749

8В оригинале использовано слово alternatively (как вариант). Прим. перев. См. https://www.rfc-editor.org/errata/eid5793

9Здесь и далее длинные строки в примерах кода разбиты на две или более строки.

10В оригинале слова «заданные в этой спецификации» отсутствуют. Прим. перев. См. https://www.rfc-editor.org/errata/eid5708

11В оригинале слова «заданные в этой спецификации» отсутствуют. Прим. перев. См. https://www.rfc-editor.org/errata/eid5708

12Слово «публичный» отсутствует в исходном документе. Прим. перев. См. https://www.rfc-editor.org/errata/eid3780

13В оригинале этот пункт содержит ошибки. Прим. перев. См. https://www.rfc-editor.org/errata/eid5332

14В оригинале ошибочно сказано о перенаправлении клиента. Прим. перев. См. https://www.rfc-editor.org/errata/eid3500

15В исходном документе строка ошибочно включала ;charset=UTF-8. Прим. перев. См. https://www.rfc-editor.org/errata/eid4679

16В исходном документе часть имени client отсутствует. Прим. перев. См. https://www.rfc-editor.org/errata/eid4819

17В исходном документе строка ошибочно включала ;charset=UTF-8. Прим. перев. См. https://www.rfc-editor.org/errata/eid4679

18В исходном документе строка ошибочно включала ;charset=UTF-8. Прим. перев. См. https://www.rfc-editor.org/errata/eid4679

19Security Assertion Markup Language — язык разметки для определения защиты.

20JavaScript Object Notation — обозначение объектов JavaScript.

21Этот и следующий пункт отсутствуют в исходном документе. Прим. перев. См. https://www.rfc-editor.org/errata/eid4745

22В исходном документе строка ошибочно включала ;charset=UTF-8. Прим. перев. См. https://www.rfc-editor.org/errata/eid4679

23Message Authentication Code — код аутентификации сообщения.

24Man-in-the-middle — «человек по средине» — атаки с перехватом и изменением трафика в пути при участии человека. Прим. перев.

25В оригинале этот блок отсутствует. Прим. перев. См. https://www.rfc-editor.org/errata/eid3904

26В исходном документе этот параграф отсутствует. Прим. перев. См. https://www.rfc-editor.org/errata/eid5873

27Опубликовано в RFC 7522. Прим. перев.

28Опубликовано в RFC 6819. Прим. перев.