О документе
Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 6750 Microsoft
Категория: Standards Track D. Hardt
ISSN: 2070-1721 Independent
Октябрь 2012
The OAuth 2.0 Authorization Framework: Bearer Token Usage
1. Введение
OAuth позволяет клиентам получать доступ к защищённым ресурсам путём
получения токена доступа, который в «The OAuth 2.0 Authorization
Framework» [RFC6749] определён как «строка, представляющая разрешение на
доступ, выданное клиенту», вместо непосредственного использования учётных
данных владельца ресурса.
Токены выдаются клиентам сервером авторизации с одобрения владельца
ресурса. Клиент использует токен доступа для доступа к защищённым ресурсам,
размещённым на сервере ресурсов. Эта спецификация описывает, как выполнять
запросы к защищённым ресурсам, когда токен доступа OAuth является токеном
предъявителя.
Эта спецификация определяет использование токенов предъявителя через
HTTP/1.1 [RFC2616] с использованием Transport Layer Security (TLS)
[RFC5246] для доступа к защищённым ресурсам. TLS обязательно реализовывать
и использовать с этой спецификацией; другие спецификации могут расширять
эту спецификацию для использования с другими протоколами. Хотя она
разработана для использования с токенами доступа,
полученными в результате потоков авторизации OAuth 2.0 [RFC6749], для
доступа к защищённым ресурсам OAuth, эта спецификация фактически определяет
общий метод авторизации HTTP, который может использоваться с токенами
предъявителя из любого источника для доступа к любым ресурсам, защищённым
этими токенами предъявителя. Схема аутентификации Bearer предназначена
прежде всего для аутентификации сервера с использованием HTTP-заголовков
WWW-Authenticate и Authorization, однако не исключает её использования для
аутентификации прокси.
1.1. Соглашения об обозначениях
Ключевые слова «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT»,
«SHOULD», «SHOULD NOT», «RECOMMENDED», «MAY» и «OPTIONAL» в этом документе
следует интерпретировать, как описано в «Key words for use in RFCs to
Indicate Requirement Levels» [RFC2119].
В этом документе используется нотация расширенной формы Бэкуса — Наура
(Augmented Backus-Naur Form, ABNF) из [RFC5234]. Кроме того, из HTTP/1.1
[RFC2617] включены следующие правила: auth-param и auth-scheme; а из
«Uniform Resource Identifier (URI): Generic Syntax» [RFC3986] —
URI-reference.
Если не указано иное, все имена и значения параметров протокола
чувствительны к регистру.
1.2. Терминология
Bearer Token
Токен безопасности, обладающий свойством, при котором любая сторона,
владеющая токеном («предъявитель»), может использовать его любым
способом, которым его может использовать любая другая владеющая им
сторона. Использование токена предъявителя не требует, чтобы
предъявитель доказывал владение криптографическим ключевым материалом
(proof-of-possession).
Все остальные термины определены в «The OAuth 2.0 Authorization
Framework» [RFC6749].
1.3. Обзор
OAuth предоставляет клиентам метод доступа к защищённому ресурсу от имени
владельца ресурса. В общем случае, прежде чем клиент сможет получить доступ
к защищённому ресурсу, он должен сначала получить разрешение на авторизацию
от владельца ресурса, а затем обменять это разрешение на токен доступа.
Токен доступа представляет область действия, продолжительность и другие
атрибуты разрешения, предоставленные разрешением на авторизацию. Клиент
получает доступ к защищённому ресурсу, предъявляя токен доступа серверу
ресурсов. В некоторых случаях клиент может непосредственно предъявить
собственные учётные данные серверу авторизации, чтобы получить токен
доступа, без необходимости сначала получать разрешение на авторизацию от
владельца ресурса.
Токен доступа предоставляет абстракцию, заменяя различные конструкции
авторизации (например, имя пользователя и пароль, утверждение) единым
токеном, понятным серверу ресурсов. Эта абстракция позволяет выдавать
токены доступа, действительные в течение короткого периода времени, а также
устраняет необходимость для сервера ресурсов понимать широкий спектр схем
аутентификации.
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Рисунок 1: Абстрактный поток протокола
Абстрактный поток OAuth 2.0, показанный на рисунке 1, описывает
взаимодействие между клиентом, владельцем ресурса, сервером авторизации и
сервером ресурсов (описанными в [RFC6749]). В этом документе определены
следующие два шага:
(E) Клиент запрашивает защищённый ресурс у сервера ресурсов и проходит
аутентификацию, предъявляя токен доступа.
(F) Сервер ресурсов проверяет токен доступа и, если он действителен,
обслуживает запрос.
Этот документ также устанавливает семантические требования к токену
доступа, возвращаемому на шаге (D).
2. Аутентифицированные запросы
В этом разделе определены три метода отправки токенов доступа предъявителя
в запросах ресурсов на серверы ресурсов. Клиенты НЕ ДОЛЖНЫ (MUST NOT)
использовать более одного метода для передачи токена в каждом запросе.
2.1. Поле заголовка запроса Authorization
При отправке токена доступа в поле заголовка запроса «Authorization»,
определённом в HTTP/1.1 [RFC2617], клиент использует схему аутентификации
«Bearer» для передачи токена доступа.
Например:
GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM
Синтаксис поля заголовка «Authorization» для этой схемы соответствует
использованию схемы Basic, определённой в разделе 2 [RFC2617]. Обратите
внимание, что, как и Basic, он не соответствует общему синтаксису,
определённому в разделе 1.2 [RFC2617], но совместим с общей инфраструктурой
аутентификации, разрабатываемой для HTTP 1.1 [HTTP-AUTH], хотя он не следует
предпочтительной практике, изложенной в ней, чтобы отразить существующие
развёртывания. Синтаксис учётных данных Bearer следующий:
b64token = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token
Клиентам СЛЕДУЕТ (SHOULD) выполнять аутентифицированные запросы с токеном
предъявителя, используя поле заголовка запроса «Authorization» со схемой
авторизации HTTP «Bearer». Серверы ресурсов ДОЛЖНЫ (MUST) поддерживать этот
метод.
2.2. Параметр тела с кодированием формы
При отправке токена доступа в теле сущности HTTP-запроса клиент добавляет
токен доступа в тело запроса, используя параметр «access_token». Клиент НЕ
ДОЛЖЕН (MUST NOT) использовать этот метод, если не выполнены все следующие
условия:
o Заголовок сущности HTTP-запроса включает поле заголовка «Content-Type»
со значением «application/x-www-form-urlencoded».
o Тело сущности соответствует требованиям к кодированию типа содержимого
«application/x-www-form-urlencoded», определённым HTML 4.01
[W3C.REC-html401-19991224].
o Тело сущности HTTP-запроса состоит из одной части.
o Содержимое, подлежащее кодированию в теле сущности, ДОЛЖНО (MUST)
состоять исключительно из символов ASCII [USASCII].
o Метод HTTP-запроса относится к числу методов, для которых определена
семантика тела запроса. В частности, это означает, что метод «GET» НЕ
ДОЛЖЕН (MUST NOT) использоваться.
Тело сущности МОЖЕТ (MAY) включать другие специфичные для запроса параметры;
в таком случае параметр «access_token» ДОЛЖЕН (MUST) быть надлежащим образом
отделён от специфичных для запроса параметров символом или символами «&»
(код ASCII 38).
Например, клиент выполняет следующий HTTP-запрос с использованием защиты
транспортного уровня:
POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
access_token=mF_9.B5f-4.1JqM
Метод «application/x-www-form-urlencoded» НЕ СЛЕДУЕТ (SHOULD NOT)
использовать, кроме как в контекстах приложений, в которых участвующие
браузеры не имеют доступа к полю заголовка запроса «Authorization». Серверы
ресурсов МОГУТ (MAY) поддерживать этот метод.
2.3. Параметр запроса URI
При отправке токена доступа в URI HTTP-запроса клиент добавляет токен
доступа в компонент запроса URI, определённый «Uniform Resource Identifier
(URI): Generic Syntax» [RFC3986], используя параметр «access_token».
Например, клиент выполняет следующий HTTP-запрос с использованием защиты
транспортного уровня:
GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1
Host: server.example.com
Строка запроса URI HTTP-запроса может включать другие параметры, относящиеся к запросу; в этом случае параметр "access_token" ДОЛЖЕН (MUST) быть надлежащим образом отделён от параметров, относящихся к запросу, с помощью символа (символов) "&" (код ASCII 38).
Например:
https://server.example.com/resource?access_token=mF_9.B5f-4.1JqM&p=q
Клиенты, использующие метод параметра запроса URI, СЛЕДУЕТ (SHOULD) также отправлять заголовок Cache-Control, содержащий параметр "no-store". Ответы сервера об успехе (статус 2XX) на эти запросы СЛЕДУЕТ (SHOULD) содержать заголовок Cache-Control с параметром "private".
Из-за недостатков безопасности, связанных с методом URI (см. раздел 5), включая высокую вероятность регистрации URL, содержащего токен доступа, его НЕ СЛЕДУЕТ (SHOULD NOT) использовать, если только невозможно передать токен доступа в поле заголовка запроса "Authorization" или в теле HTTP-запроса. Серверы ресурсов МОГУТ (MAY) поддерживать этот метод.
Этот метод включён для документирования текущего использования; его использование не рекомендуется из-за недостатков его безопасности (см. раздел 5), а также потому, что он использует зарезервированное имя параметра запроса, что противоречит лучшим практикам пространства имён URI согласно "Architecture of the World Wide Web, Volume One" [W3C.REC-webarch-20041215].
3. Поле заголовка ответа WWW-Authenticate
Если запрос защищённого ресурса не включает учётные данные аутентификации или не содержит токена доступа, обеспечивающего доступ к защищённому ресурсу, сервер ресурсов ДОЛЖЕН (MUST) включить поле заголовка ответа HTTP "WWW-Authenticate"; он также МОЖЕТ (MAY) включать его в ответ на другие условия. Поле заголовка "WWW-Authenticate" использует каркас, определённый HTTP/1.1 [RFC2617].
Все вызовы аутентификации, определённые этой спецификацией, ДОЛЖНЫ (MUST) использовать значение auth-scheme "Bearer". За этой схемой ДОЛЖНО (MUST) следовать одно или более значений auth-param. Атрибуты auth-param, используемые или определяемые этой спецификацией, приведены ниже. Также МОГУТ (MAY) использоваться другие атрибуты auth-param.
Атрибут "realm" МОЖЕТ (MAY) быть включён для указания области защиты способом, описанным в HTTP/1.1 [RFC2617]. Атрибут "realm" НЕ ДОЛЖЕН (MUST NOT) появляться более одного раза.
Атрибут "scope" определён в разделе 3.3 [RFC6749]. Атрибут "scope" представляет собой разделённый пробелами список чувствительных к регистру значений области действия, указывающих область действия токена доступа, необходимую для доступа к запрошенному ресурсу. Значения "scope" определяются реализацией; централизованного реестра для них не существует; допустимые значения определяются сервером авторизации. Порядок значений "scope" несущественен. В некоторых случаях значение "scope" будет использоваться при запросе нового токена доступа с областью доступа, достаточной для использования защищённого ресурса. Использование атрибута "scope" НЕОБЯЗАТЕЛЬНО (OPTIONAL). Атрибут "scope" НЕ ДОЛЖЕН (MUST NOT) появляться более одного раза. Значение "scope" предназначено для программного использования и не предназначено для отображения конечным пользователям.
Ниже приведены два примера значений области действия; они взяты соответственно из вариантов использования OAuth 2.0 OpenID Connect [OpenID.Messages] и Online Multimedia Authorization Protocol [OMAP] комитета Open Authentication Technology Committee (OATC):
scope="openid profile email"
scope="urn:example:channel=HBO&urn:example:rating=G,PG-13"
Если запрос защищённого ресурса включал токен доступа и аутентификация не удалась, серверу ресурсов СЛЕДУЕТ (SHOULD) включить атрибут "error", чтобы предоставить клиенту причину отклонения запроса на доступ. Значение параметра описано в разделе 3.1. Кроме того, сервер ресурсов МОЖЕТ (MAY) включить атрибут "error_description", чтобы предоставить разработчикам удобочитаемое объяснение, не предназначенное для отображения конечным пользователям. Он также МОЖЕТ (MAY) включить атрибут "error_uri" с абсолютным URI, идентифицирующим удобочитаемую веб-страницу, объясняющую ошибку. Атрибуты "error", "error_description" и "error_uri" НЕ ДОЛЖНЫ (MUST NOT) появляться более одного раза.
Значения атрибута "scope" (указанные в приложении A.4 [RFC6749]) НЕ ДОЛЖНЫ (MUST NOT) включать символы вне набора %x21 / %x23-5B / %x5D-7E для представления значений области действия и %x20 для разделителей между значениями области действия. Значения атрибутов "error" и "error_description" (указанные в приложениях A.7 и A.8 [RFC6749]) НЕ ДОЛЖНЫ (MUST NOT) включать символы вне набора %x20-21 / %x23-5B / %x5D-7E. Значения атрибута "error_uri" (указанные в приложении A.9 [RFC6749]) ДОЛЖНЫ (MUST) соответствовать синтаксису URI-reference и, следовательно, НЕ ДОЛЖНЫ (MUST NOT) включать символы вне набора %x21 / %x23-5B / %x5D-7E.
Например, в ответ на запрос защищённого ресурса без аутентификации:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
А в ответ на запрос защищённого ресурса с попыткой аутентификации с использованием истёкшего токена доступа:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
error="invalid_token",
error_description="The access token expired"
3.1. Коды ошибок
Когда запрос завершается неудачей, сервер ресурсов отвечает с использованием соответствующего кода состояния HTTP (обычно 400, 401, 403 или 405) и включает в ответ один из следующих кодов ошибок:
invalid_request
В запросе отсутствует обязательный параметр, он включает неподдерживаемый параметр или значение параметра, повторяет один и тот же параметр, использует более одного метода включения токена доступа или иным образом является некорректно сформированным. Серверу ресурсов СЛЕДУЕТ (SHOULD) отвечать с кодом состояния HTTP 400 (Bad Request).
invalid_token
Предоставленный токен доступа истёк, отозван, некорректно сформирован или недействителен по иным причинам. Ресурсу СЛЕДУЕТ (SHOULD) ответить с кодом состояния HTTP 401 (Unauthorized). Клиент МОЖЕТ (MAY) запросить новый токен доступа и повторить запрос защищённого ресурса.
insufficient_scope
Запрос требует более высоких привилегий, чем предоставляемые токеном доступа. Серверу ресурсов СЛЕДУЕТ (SHOULD) отвечать с кодом состояния HTTP 403 (Forbidden) и он МОЖЕТ (MAY) включить атрибут "scope" с областью действия, необходимой для доступа к защищённому ресурсу.
Если в запросе отсутствует какая-либо информация аутентификации (например, клиент не знал, что аутентификация необходима, или предпринял попытку с использованием неподдерживаемого метода аутентификации), серверу ресурсов НЕ СЛЕДУЕТ (SHOULD NOT) включать код ошибки или другую информацию об ошибке.
Например:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
4. Пример ответа с токеном доступа
Обычно токен Bearer возвращается клиенту как часть ответа OAuth 2.0 [RFC6749] с токеном доступа. Пример такого ответа:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"mF_9.B5f-4.1JqM",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
5. Соображения безопасности
В этом разделе описываются относящиеся к обработке токенов угрозы безопасности при использовании токенов Bearer и способы смягчения этих угроз.
5.1. Угрозы безопасности
В следующем списке представлены несколько распространённых угроз протоколам, использующим некоторую форму токенов. Этот список угроз основан на специальной публикации NIST 800-63 [NIST800-63]. Поскольку этот документ основан на спецификации авторизации OAuth 2.0 [RFC6749], мы исключаем обсуждение угроз, описанных в ней или связанных документах.
Изготовление/изменение токена: злоумышленник может сгенерировать поддельный токен или изменить содержимое токена (например, утверждения аутентификации или атрибутов) существующего токена, что заставит сервер ресурсов предоставить клиенту ненадлежащий доступ. Например, злоумышленник может изменить токен, чтобы продлить срок его действия; вредоносный клиент может изменить утверждение, чтобы получить доступ к информации, которую он не должен иметь возможности просматривать.
Раскрытие токена: токены могут содержать утверждения аутентификации и атрибутов, включающие конфиденциальную информацию.
Перенаправление токена: злоумышленник использует токен, созданный для использования одним сервером ресурсов, чтобы получить доступ к другому серверу ресурсов, который ошибочно считает, что токен предназначен для него.
Повторное воспроизведение токена: злоумышленник пытается использовать токен, который уже использовался с этим сервером ресурсов в прошлом.
5.2. Смягчение угроз
Широкий спектр угроз может быть смягчён защитой содержимого токена с использованием цифровой подписи или кода аутентификации сообщения (MAC). В качестве альтернативы токен Bearer может содержать ссылку на информацию авторизации, а не непосредственно кодировать эту информацию. Такие ссылки ДОЛЖНЫ (MUST) быть практически невозможными для угадывания злоумышленником; использование ссылки может потребовать дополнительного взаимодействия между сервером и издателем токена для разрешения ссылки в информацию авторизации. Механика такого взаимодействия этой спецификацией не определена.
Этот документ не определяет кодирование или содержимое токена; следовательно, подробные рекомендации о средствах обеспечения защиты целостности токена выходят за рамки этого документа. Защита целостности токена ДОЛЖНА (MUST) быть достаточной, чтобы предотвратить изменение токена.
Для противодействия перенаправлению токена серверу авторизации важно включать в токен идентификатор предполагаемых получателей (аудитории), обычно одного сервера ресурсов (или списка серверов ресурсов). Также СЛЕДУЕТ (RECOMMENDED) ограничить использование токена конкретной областью действия.
Сервер авторизации ДОЛЖЕН (MUST) реализовать TLS. То, какие версии следует реализовать, будет меняться со временем и зависеть от широкого развёртывания и известных уязвимостей безопасности на момент реализации. На момент написания этого документа TLS версии 1.2 [RFC5246] является самой новой версией, но её фактическое развёртывание весьма ограничено, и она может быть нелегко доступна в наборах инструментов реализации. TLS версии 1.0 [RFC2246] является наиболее широко развёрнутой версией и обеспечит самую широкую совместимость.
Для защиты от раскрытия токена ДОЛЖНА (MUST) применяться защита конфиденциальности с использованием TLS [RFC5246] с набором шифров, обеспечивающим защиту конфиденциальности и целостности. Это требует, чтобы взаимодействие по обмену данными между клиентом и сервером авторизации, а также взаимодействие между клиентом и сервером ресурсов использовали защиту конфиденциальности и целостности. Поскольку TLS обязательно реализовать и использовать с этой спецификацией, это предпочтительный подход для предотвращения раскрытия токена через канал связи. В тех случаях, когда клиент не может наблюдать содержимое токена, в дополнение к использованию защиты TLS ДОЛЖНО (MUST) применяться шифрование токена. В качестве дополнительной защиты от раскрытия токена клиент ДОЛЖЕН (MUST) проверять цепочку сертификатов TLS при выполнении запросов к защищённым ресурсам, включая проверку списка отзыва сертификатов (CRL) [RFC5280].
Файлы cookie обычно передаются в открытом виде. Следовательно, любая содержащаяся в них информация подвержена риску раскрытия. Поэтому токены Bearer НЕ ДОЛЖНЫ (MUST NOT) храниться в файлах cookie, которые могут передаваться в открытом виде. См. "HTTP State Management Mechanism" [RFC6265] относительно соображений безопасности, касающихся файлов cookie.
В некоторых развёртываниях, в том числе использующих балансировщики нагрузки, соединение TLS с сервером ресурсов завершается до фактического сервера, предоставляющего ресурс. Это может оставить токен незащищённым между внешним сервером, на котором завершается соединение TLS, и внутренним сервером, предоставляющим ресурс. В таких развёртываниях ДОЛЖНЫ (MUST) применяться достаточные меры для обеспечения конфиденциальности токена между внешним и внутренним серверами; одной из таких возможных мер является шифрование токена.
Для противодействия перехвату и повторному воспроизведению токена
даются следующие рекомендации: во-первых, срок действия токена ДОЛЖЕН
(MUST) быть ограничен; одним из способов достижения этого является
размещение поля времени действия внутри защищённой части токена. Обратите
внимание, что использование краткоживущих (один час или менее) токенов
снижает последствия их утечки. Во-вторых, ДОЛЖНА (MUST) применяться
защита конфиденциальности обменов между клиентом и сервером авторизации,
а также между клиентом и сервером ресурсов. Вследствие этого никакой
перехватчик на пути передачи данных не способен наблюдать обмен токеном.
Следовательно, такой противник на пути передачи данных не может повторно
воспроизвести токен. Кроме того, при предъявлении токена серверу ресурсов
клиент ДОЛЖЕН (MUST) проверить идентичность этого сервера ресурсов в
соответствии с разделом 3.1 документа "HTTP Over TLS" [RFC2818]. Обратите
внимание, что клиент ДОЛЖЕН (MUST) проверять цепочку TLS-сертификатов при
выполнении этих запросов к защищённым ресурсам. Предъявление токена
неаутентифицированному и неавторизованному серверу ресурсов или отказ от
проверки цепочки сертификатов позволит противникам похитить токен и
получить несанкционированный доступ к защищённым ресурсам.
5.3. Сводка рекомендаций
Защищайте bearer-токены: реализации клиентов ДОЛЖНЫ (MUST) обеспечивать,
чтобы bearer-токены не раскрывались непредназначенным сторонам,
поскольку те смогут использовать их для получения доступа к защищённым
ресурсам. Это основное соображение безопасности при использовании
bearer-токенов, лежащее в основе всех последующих более конкретных
рекомендаций.
Проверяйте цепочки TLS-сертификатов: клиент ДОЛЖЕН (MUST) проверять
цепочку TLS-сертификатов при выполнении запросов к защищённым ресурсам.
Невыполнение этого требования может позволить атакам с перехватом DNS
похитить токен и получить непреднамеренный доступ.
Всегда используйте TLS (https): клиенты ДОЛЖНЫ (MUST) всегда использовать
TLS [RFC5246] (https) либо эквивалентную защиту транспорта при
выполнении запросов с bearer-токенами. Невыполнение этого требования
подвергает токен многочисленным атакам, которые могут предоставить
атакующим непреднамеренный доступ.
Не храните bearer-токены в cookies: реализации НЕ ДОЛЖНЫ (MUST NOT)
хранить bearer-токены в cookies, которые могут передаваться в открытом
виде (что является режимом передачи cookies по умолчанию). Реализации,
которые всё же хранят bearer-токены в cookies, ДОЛЖНЫ (MUST) принимать
меры предосторожности против межсайтовой подделки запросов.
Выпускайте краткоживущие bearer-токены: серверы токенов СЛЕДУЕТ (SHOULD)
выпускать краткоживущие (один час или менее) bearer-токены, особенно
при выпуске токенов клиентам, работающим в веб-браузере или иных средах,
в которых возможна утечка информации. Использование краткоживущих
bearer-токенов может снизить последствия их утечки.
Выпускайте bearer-токены с ограниченной областью действия: серверам токенов
СЛЕДУЕТ (SHOULD) выпускать bearer-токены, содержащие ограничение
аудитории, ограничивающее их использование предполагаемой доверяющей
стороной или набором доверяющих сторон.
Не передавайте bearer-токены в URL страниц: bearer-токены НЕ СЛЕДУЕТ
(SHOULD NOT) передавать в URL страниц (например, как параметры строки
запроса). Вместо этого bearer-токены СЛЕДУЕТ (SHOULD) передавать в
заголовках HTTP-сообщений или телах сообщений, для которых принимаются
меры обеспечения конфиденциальности. Браузеры, веб-серверы и другое
программное обеспечение могут недостаточно надёжно защищать URL в
истории браузера, журналах веб-сервера и иных структурах данных. Если
bearer-токены передаются в URL страниц, атакующие могут получить
возможность похитить их из данных истории, журналов или других
незащищённых мест.
6.1. Регистрация типа токена доступа OAuth
Эта спецификация регистрирует следующий тип токена доступа в реестре OAuth
Access Token Types, определённом в [RFC6749].
6.1.1. Тип токена доступа OAuth "Bearer"
Имя типа:
Bearer
Дополнительные параметры ответа конечной точки токенов:
(отсутствуют)
Схема(ы) HTTP-аутентификации:
Bearer
Контролёр изменений:
IETF
Документ(ы) спецификации:
RFC 6750
6.2. Регистрация ошибок расширений OAuth
Эта спецификация регистрирует следующие значения ошибок в реестре OAuth
Extensions Error, определённом в [RFC6749].
6.2.1. Значение ошибки "invalid_request"
Имя ошибки:
invalid_request
Место использования ошибки:
Ответ об ошибке доступа к ресурсу
Связанное расширение протокола:
Тип токена доступа Bearer
Контролёр изменений:
IETF
Документ(ы) спецификации:
RFC 6750
6.2.2. Значение ошибки "invalid_token"
Имя ошибки:
invalid_token
Место использования ошибки:
Ответ об ошибке доступа к ресурсу
Связанное расширение протокола:
Тип токена доступа Bearer
Контролёр изменений:
IETF
Документ(ы) спецификации:
RFC 6750
6.2.3. Значение ошибки "insufficient_scope"
Имя ошибки:
insufficient_scope
Место использования ошибки:
Ответ об ошибке доступа к ресурсу
Связанное расширение протокола:
Тип токена доступа Bearer
Контролёр изменений:
IETF
Документ(ы) спецификации:
RFC 6750
7.1. Нормативные ссылки
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, март 1997 г.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, январь 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, июнь 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, июнь 1999 г.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, май 2000 г.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, январь 2005 г.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, январь 2008 г.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
август 2008 г.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, май 2008 г.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
апрель 2011 г.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, октябрь 2012 г.
[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
REC-html401-19991224, декабрь 1999 г.,
<http://www.w3.org/TR/1999/REC-html401-19991224>.
[W3C.REC-webarch-20041215]
Jacobs, I. and N. Walsh, "Architecture of the World Wide
Web, Volume One", рекомендация World Wide Web Consortium
REC-webarch-20041215, декабрь 2004 г.,
<http://www.w3.org/TR/2004/REC-webarch-20041215>.
7.2. Информативные ссылки
[HTTP-AUTH] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", незавершённая
работа, октябрь 2012 г.
[NIST800-63] Burr, W., Dodson, D., Newton, E., Perlner, R., Polk, T.,
Gupta, S., and E. Nabbus, "NIST Special Publication
800-63-1, INFORMATION SECURITY", декабрь 2011 г.,
<http://csrc.nist.gov/publications/>.
[OMAP] Huff, J., Schlacht, D., Nadalin, A., Simmons, J.,
Rosenberg, P., Madsen, P., Ace, T., Rickelton-Abdi, C.,
and B. Boyer, "Online Multimedia Authorization Protocol:
An Industry Standard for Authorized Access to Internet
Multimedia Resources", апрель 2012 г.,
<http://www.oatc.us/Standards/Download.aspx>.
[OpenID.Messages]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B.,
Mortimore, C., and E. Jay, "OpenID Connect Messages
1.0", июнь 2012 г., <http://openid.net/specs/
openid-connect-messages-1_0.html>.
Приложение A. Благодарности
Следующие люди участвовали в создании предварительных версий этого
документа: Blaine Cook (BT), Brian Eaton (Google), Yaron Y. Goland
(Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter),
Luke Shepard (Facebook) и Allen Tom (Yahoo!). Содержание и концепции,
изложенные в нём, являются результатом работы сообщества OAuth, сообщества
Web Resource Authorization Profiles (WRAP) и рабочей группы OAuth. David
Recordon создал предварительную версию этой спецификации на основе раннего
черновика спецификации, развившегося в OAuth 2.0 [RFC6749]. Michael B.
Jones, в свою очередь, создал первую версию (00) этой спецификации,
используя части предварительного документа David, и отредактировал все
последующие версии.
В рабочей группе OAuth имеются десятки очень активных участников, которые
предлагали идеи и формулировки для этого документа, включая Michael Adams,
Amanda Anganes, Andrew Arnott, Derek Atkins, Dirk Balfanz, John Bradley,
Brian Campbell, Francisco Corella, Leah Culver, Bill de hOra, Breno de
Medeiros, Brian Ellin, Stephen Farrell, Igor Faynberg, George Fletcher,
Tim Freeman, Evan Gilbert, Yaron Y. Goland, Eran Hammer, Thomas Hardjono,
Dick Hardt, Justin Hart, Phil Hunt, John Kemp, Chasen Le Hara, Barry Leiba,
Amos Jeffries, Michael B. Jones, Torsten Lodderstedt, Paul Madsen, Eve
Maler, James Manger, Laurence Miao, William J. Mills, Chuck Mortimore,
Anthony Nadalin, Axel Nennker, Mark Nottingham, David Recordon, Julian
Reschke, Rob Richards, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob
Sayre, Marius Scurtescu, Naitik Shah, Justin Smith, Christian Stuebner,
Jeremy Suriel, Doug Tangren, Paul Tarjan, Hannes Tschofenig, Franklin Tse,
Sean Turner, Paul Walker, Shane Weeden, Skylar Woodward и Zachary Zeltsan.