Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 6750 Microsoft
Category: Standards Track D. Hardt
ISSN: 2070-1721 Independent
October 2012
The OAuth 2.0 Authorization Framework: Bearer Token Usage
Схема проверки полномочий OAuth 2.0: использованием маркера на предъявителя
Аннотация
В этой спецификации описано использование маркеров на предъявителя (bearer token) в запросах HTTP для доступа к защищённым ресурсам через OAuth 2.0. Любая сторона, владеющая таким маркером, может использовать его для доступа к соответствующим ресурсам (без демонстрации владения криптографическим ключом). Для предотвращения злоупотреблений маркеры должны быть защищены от раскрытия при хранении и транспортировке.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 5741.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc6750.
Авторские права
Авторские права (Copyright (c) 2012) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
1. Введение
OAuth обеспечивает клиентам доступ к защищённым ресурсам после получения маркера доступа, определённого в «The OAuth 2.0 Authorization Framework» [RFC6749] как «строки, представляющей разрешение на доступ, выданное клиенту». Маркер применяется взамен передачи учётных данных владельца ресурса. Маркеры выдаёт клиентам сервер авторизации с одобрения владельца ресурса. Клиент использует этот маркер для доступа к защищённым ресурсам, размещённым на сервере ресурсов. В этой спецификации описаны запросы к ресурсам с использованием маркера доступа OAuth, являющегося маркером на предъявителя (bearer).
Эта спецификация определяет использование маркеров на предъявителя с HTTP/1.1 [RFC2616] по протоколу TLS3 [RFC5246] для доступа к защищённым ресурсам. Протокол TLS обязателен для реализации и использования с данной спецификацией. Другие спецификации могут разрешать применение иных протоколов. Хотя данная спецификация разработана для использования с маркерами доступа, выданными по результату авторизации OAuth 2.0 [RFC6749] для доступа к защищённым OAuth ресурсам, фактически она задаёт базовый метод авторизации HTTP, который может применяться с маркерами на предъявителя из любого источника для доступа к ресурсам, защищаемым такими маркерами. Схема Bearer-аутентификации предназначена в первую очередь для серверов аутентификации, использующих заголовки WWW-Authenticate и HTTP Authorization, но может работать и с прокси-аутентификацией.
1.1. Соглашения о нотации
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119 [RFC2119].
В этой спецификации применяется нотация ABNF4 [RFC5234], а также включено правило ссылок URI из «Uniform Resource Identifier (URI): Generic Syntax» [RFC3986].
Если явно не указано иное, регистр символов в именах и значениях параметров принимается во внимание.
1.2. Терминология
Bearer Token — маркер на предъявителя
Маркер безопасности, который может предъявить любая владеющая им сторона (предъявитель) любым поддерживаемым способом. Для использования такого маркера от предъявителя не требуется какой-либо криптографический ключевой материал (подтверждение владения).
Все прочие термины определены в «The OAuth 2.0 Authorization Framework» [RFC6749].
1.3. Обзор
OAuth предоставляет клиентам метод доступа к защищённым ресурсам от имени владельца ресурса. В общем случае для доступа к ресурсу клиент должен сначала получить разрешение (authorization grant) владельца ресурса, а затем сменить это разрешение на маркер доступа (access token). Маркер доступа указывает область и срок действия, а также имеет другие атрибуты, предоставленные разрешением. Клиент обращается к защищённому ресурсу, предоставляя маркер доступа серверу ресурсов. В некоторых случаях клиент может напрямую представлять свои учётные данные серверу авторизации для получения маркера доступа без предварительного разрешения владельца ресурса.
Маркер доступа обеспечивает абстракцию, заменяющую различные варианты авторизации (например, имя пользователя, пароль, утверждение — assertion) одним маркером, понятным серверу ресурсов. Эта абстракция позволяет выдавать краткосрочные маркеры доступа, а также избавляет сервер ресурсов от необходимости разбираться с широким диапазоном схем проверки подлинности (аутентификации).
+--------+ +---------------+ | |--(A)- Authorization Request ->| Владелец | | | | ресурса | | |<-(B)-- Authorization Grant ---| | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Сервер | | Клиент | | авторизации | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Сервер | | | | ресурсов | | |<-(F)--- Protected Resource ---| | +--------+ +---------------+
Рисунок 1. Абстрактный поток протокола.
Абстракция потока обмена OAuth 2.0, показанная на рисунке 1, описывает взаимодействия между клиентом, владельцем ресурса, сервером авторизации и сервером ресурсов (см. [RFC6749]). Этот документ описывает 2 этапа:
(E) клиент запрашивает защищённый ресурс у сервера ресурсов и аутентифицируется по маркеру доступа;
(F) сервер ресурсов проверяет маркер доступа и обслуживает или отвергает запрос по результатам проверки.
Документ также задаёт семантические требования к маркеры доступа, выдаваемому на этапе (D).
2. Аутентифицированные запросы
В этом разделе описаны 3 метода отправки маркеров доступа на предъявителя в запросах к серверу ресурсов. Клиентам недопустимо применять более одного метода передачи маркера для каждого запроса ресурса.
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 для этой схемы соответствует использованию базовой схемы, заданной в разделе 2 [RFC2617]. Отметим, что, как и в случае Basic, синтаксис не соответствует базовому синтаксису, заданному в параграфе 1.2 [RFC2617], но совместим с общей схемой аутентификации, разработанной для HTTP 1.1 [HTTP-AUTH], хотя и не соответствует указанной там предпочтительной практике, основанной на имеющихся внедрениях. Синтаксис свидетельств (credentials) Bearer показан ниже.
token685 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=" credentials = "Bearer" 1*SP token68
Клиентам следует передавать аутентифицированные запросы с маркером на предъявителя в поле заголовка Authorization, указывая схему авторизации HTTP Bearer. Серверы ресурсов должны поддерживать этот метод.
2.2. Параметр в теле запроса
При отправке маркера доступа в теле запроса HTTP клиент добавляет маркер как параметр access_token. Клиенту недопустимо использовать этот метод, если не выполняются все указанные ниже условия.
-
Заголовок HTTP entity-header включает поле Content-Type со значением application/x-www-form-urlencoded.
-
Тело заголовка кодируется в соответствии со схемой application/x-www-form-urlencoded, заданной в HTML 4.01 [W3C.REC-html401-19991224].
-
Тело запроса HTTP состоит из 1 части.
-
Содержимое кодированного тела запроса должно содержать только символы ASCII [USASCII].
-
Метод запроса HTTP должен иметь определённую семантику. В частности, недопустимо применение GET.
Тело запроса может включать специфичные для запроса параметры и в этом случае параметр access_token должен подобающим образом отделяться от таких параметров с помощью символов & (код 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 не следует применять в контексте приложений, где используемые браузеры могут иметь доступ к полю заголовка запроса Authorization. Серверы ресурсов могут поддерживать этот метод.
2.3. Параметр URI Query
При отправке маркера доступа в URI запроса HTTP клиент добавляет маркер в компонент URI query, как указано в «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 query в запросе HTTP может включать специфичные для запроса параметры и в этом случае параметр access_token должен подобающим образом отделяться от таких параметров с помощью символов & (код ASCII 38).
https://server.example.com/resource?access_token=mF_9.B5f-4.1JqM&p=q
Клиентам, использующим параметр URI query, следует также передавать заголовок Cache-Control с опцией no-store. В отклики сервера об успехе (коды 2XX) следует включать заголовок Cache-Control с опцией private.
По причине слабости защиты метода URI (см. раздел 5), включая высокую вероятность записи в журналы URL с маркером доступа, метод не следует применять, если возможно использовать иные методы (поле заголовка Authorization или содержимое тела запроса HTTP). Серверы ресурсов могут поддерживать этот метод.
Этот метод включён в спецификацию для документирования текущей практики. Его использование не рекомендуется из-за слабости защиты (см. раздел 5), а также по причине применения резервного параметра query, противоречащего современной практике для пространства имён URI, описанной в «Architecture of the World Wide Web, Volume One» [W3C.REC-webarch-20041215].
3. Поле заголовка отклика WWW-Authenticate
Если запрос защищённого ресурса не включает учётных данных для аутентификации или маркера, разрешающего доступ к ресурсу, сервер ресурса должен включать в отклик поле заголовка HTTP WWW-Authenticate. Такой заголовок может включаться в отклики и при иных условиях. Поле заголовка WWW-Authenticate использует схему, заданную в HTTP/1.1 [RFC2617].
Все свидетельства, заданные этой спецификацией, должны использовать auth-scheme со значением Bearer. За этой схемой должно следовать одно или несколько значений auth-param. Атрибуты auth-param описаны ниже. Могут применяться и другие атрибуты auth-param.
Атрибут realm можно включать для указания защищённой области, как описано в HTTP/1.1 [RFC2617]. Этот атрибут недопустимо включать более 1 раза.
Атрибут scope определён в параграфе 3.3 [RFC6749] и представляет собой список разделённых пробелами значений (с учётом регистра символов), указывающих требуемую область действия маркера доступа. Значения определяются реализацией, централизованного реестра для них нет и разрешены значения, заданные сервером авторизации. Порядок элементов списка не учитывается. В некоторых случаях значение поля scope применяется при запросе нового маркера доступа с достаточной областью действия для использования с защищаемым ресурсом. Применение атрибута scope является необязательным и недопустимо включать его более 1 раза. Значение scope предназначено для программной обработки, а не для отображения конечному пользователю.
Ниже приведены два значения scope, взятые из примеров использования OAuth 2.0 OpenID Connect [OpenID.Messages] и Open Authentication Technology Committee (OATC) Online Multimedia Authorization Protocol [OMAP].
scope="openid profile email"
scope="urn:example:channel=HBO&urn:example:rating=G,PG-13"
Если запрос доступа к ресурсу с маркером доступа не прошёл проверку подлинности, серверу ресурса следует включать в отклик атрибут error для информирования клиента о причине отклонения доступа (см. параграф 3.1). Сервер ресурса может включить в отклик атрибут error_description с понятным человеку значением для информирования разработчика (конечному пользователю не выводится), а также атрибут error_uri с абсолютным URI web-страницы с понятным человеку описанием ошибки. Атрибуты error, error_description и error_uri недопустимо включать более 1 раза.
В значения атрибута scope (см. Приложение A.4 к [RFC6749]) недопустимо включать символы, кроме %x21 / %x23-5B / %x5D-7E для представления областей действия и пробела (%x20) в качестве разделителя. В значения атрибутов error и error_description (см. Приложения A.7 и A.8 к [RFC6749]) недопустимо включать символы, кроме %x20-21 / %x23-5B / %x5D-7E. Значения атрибута error_uri (см. Приложение A.9 к [RFC6749]) должны соответствовать синтаксису ссылок URI и недопустимо включать в них символы, отличные от %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
В запросе нет обязательного параметра, имеются неподдерживаемые параметры или значения, указано несколько методов включения маркера запроса или имеются иные нарушения. Серверу ресурсов следует отвечать кодом HTTP 400 (Bad Request).
invalid_token
Представленный маркер доступа просрочен, отозван, некорректно сформирован или запрос недействителен по иной причине. Серверу ресурсов следует отвечать кодом HTTP 401 (Unauthorized). Клиент может запросить новый маркер доступа и повторить попытку запроса защищённого ресурса.
insufficient_scope
Запрос требует более высоких привилегий, нежели предоставляет маркер доступа. Серверу ресурсов следует отвечать кодом HTTP 403 (Forbidden) и можно включать в отклик атрибут scope, указывающий область действия, требуемую для доступа к ресурсу.
Если запрос не содержит данных для аутентификации (например, клиент не знает о необходимости проверки подлинности или пытается использовать неподдерживаемый метод аутентификации), серверу ресурса не следует включать в отклик код ошибки и другие сведения об ошибке. Например,
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
4. Пример отклика с маркером доступа
Обычно маркер доступа на предъявителя возвращается клиенту как часть отклика OAuth 2.0 [RFC6749] с маркером доступа, например,
HTTP/1.1 200 OK
Content-Type: application/json6
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"mF_9.B5f-4.1JqM",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
5. Вопросы безопасности
В этом разделе описаны угрозы безопасности, связанные с обработкой маркеров доступа на предъявителя, и рассмотрены способы снижения таких угроз.
5.1. Угрозы безопасности
Ниже перечислено несколько распространённых типов угроз для протоколов, использующих различные формы маркеров, на основе документа «NIST Special Publication 800-63» [NIST800-63]. Поскольку данный документ основан на спецификации OAuth 2.0 [RFC6749], здесь не указаны угрозы, описанные в ней и связанных документах.
Подделка и изменение маркеров
Злоумышленник может создать поддельный маркер или изменить содержимое имеющегося (например, аутентификацию или атрибуты), вынуждая сервер ресурсов предоставить клиенту неправомерный доступ. Например, атакующий может расширить срок действия маркера или враждебный клиент может изменить притязания для получения доступа к информации, которая не предназначена для него.
Раскрытие маркеров
Маркеры могут включать данные аутентификации или атрибуты, содержащие деликатные сведения.
Перенаправление маркеров
Злоумышленник использует маркер, созданный для использования с одним сервером ресурсов, на другом сервере, который ошибочно сочтёт маркер предназначенным для него.
Повторное использование маркеров
Атакующий пытается использовать маркер, который уже применялся для доступа к этому ресурсу в прошлом.
5.2. Снижение угроз
Многие угрозы можно смягчить путём защиты содержимого маркеров с помощью цифровых подписей или кодов аутентификации сообщения (Message Authentication Code или MAC). Можно также включать в маркер на предъявителя ссылку на данные для авторизации вместо их кодирования напрямую. Такие ссылки должны быть непредсказуемыми для злоумышленника, а для их использования может требоваться дополнительное взаимодействие между сервером и эмитентом маркера для преобразования ссылки на данные авторизации. Спецификация не задаёт таких механизмов.
Этот документ не задаёт содержимое и кодирование маркеров, поэтому детальные рекомендации по мерам защиты целостности маркеров выходят за рамки документа. Защита целостности маркеров должна быть достаточно сильной, чтобы маркеры невозможно было изменить.
Чтобы справиться с перенаправлением маркеров серверу авторизации важно включать в маркеры сведения для идентификации предусмотренных получателей (аудитории) одного или нескольких серверов ресурсов. Рекомендуется также ограничивать применение маркера конкретной областью.
Сервер авторизации должен поддерживать TLS. Выбор реализуемых версий зависит от распространённости и сведений об уязвимостях разных версий. К моменту написания этого документа наиболее свежей была версия TLS 1.2 [RFC5246], но она ещё не получила широкого распространения и может оказаться недоступной для некоторых систем. Версия TLS 1.0 [RFC2246] распространена наиболее широко и обеспечит максимальную совместимость.
Для предотвращения раскрытия маркеров должна применяться защита конфиденциальности с использованием TLS [RFC5246] и подходящими для обеспечения целостности и конфиденциальности шифрами. Это обеспечит целостность и конфиденциальность взаимодействий между клиентом и сервером авторизации, а также между клиентом и сервером ресурсов. Поскольку реализация TLS обязательна и протокол используется в этой спецификации, такой подход предпочтителен для предотвращения раскрытия маркеров в каналах связи. В случаях, когда клиенту должно быть недоступно содержимое маркера, нужно применять шифрование маркеров в дополнение к защите TLS. В качестве дополнительной защиты от раскрытия маркеров клиенты при запросах к защищённым ресурсам должны проверять цепочку сертификатов TLS, включая списки отзыва (Certificate Revocation List или CRL) [RFC5280].
Cookie обычно передаются в открытом виде и содержащиеся в них сведения могут быть раскрыты. Поэтому маркеры на предъявителя недопустимо помещать в cookie, передаваемые в открытом виде. Вопросы безопасности cookie рассмотрены в «HTTP State Management Mechanism» [RFC6265].
В некоторых случяаях, включая системы с балансированием нагрузки, соединение TLS с сервером ресурсов может завершаться, не доходя до сервера, фактически поддерживающего ресурс. Это может приводить к снятию защиты маркера между сервером front-end, на котором завершается соединение TLS, и поддерживающим ресурс сервером back-end. В таких системах должны приниматься меры, достаточные для обеспечения конфиденциальности между серверами front-end и back-end. Одной из возможных мер является шифрование маркеров.
Для предотвращения захвата и последующего воспроизведения маркера (replay) предлагается несколько мер. Во-первых, срок действия маркера должен ограничиваться, например, путём внедрения поля со сроком действия в защищённую часть маркера. Отметим, что краткосрочные (не более 1 часа) маркеры менее подвержены утечкам. Во-вторых, должна обеспечиваться защита конфиденциальности обменов данными между клиентом и сервером ресурсов, в результате чего злоумышленник на пути обмена не сможет отследить обмен маркерами и использовать перехваченные маркеры. Кроме того, при предъявлении маркера серверу ресурсов клиент должен подтвердить серверу свою подлинность (аутентификация), как описано в параграфе 3.1 «HTTP Over TLS» [RFC2818]. Отметим, что клиент должен проверять цепочку сертификации TLS при отправке запросов к защищённым ресурсам. Предъявление маркера неаутентифицированному и неуполномоченному серверу ресурсов или отказ от проверки цепочки сертификатов позволит атакующему украсть маркер и получить несанкционированный доступ к защищённому ресурсу.
5.3. Сводка рекомендаций
Защита маркеров на предъявителя
Реализации клиентов должны предотвращать утечку маркеров к посторонним, поскольку те смогут применить маркеры для получения доступа к защищённым ресурсам. Это основной аспект безопасности при использовании маркеров на предъявителя, лежащий в основе всех последующих рекомендаций.
Проверка цепочек сертификации TLS
Клиент должен проверять цепочку сертификатов TLS при запросах к защищаемым ресурсам. Отказ от проверки ведёт к риску атак с перехватом DNS (hijacking) для кражи маркеров и получения несанкционированного доступа.
Использование TLS (https)
Клиенты должны всегда использовать TLS [RFC5246] (https) или эквивалентную защиту на транспортном уровне при запросах с маркером на предъявителя. Отказ от этого ведёт к риску многочисленных атак с получением злоумышленником несанкционированного доступа к защищаемым ресурсам.
Предотвращение включения маркеров на предъявителя в cookie
Реализациям недопустимо помещать маркеры на предъявителя в cookie, передаваемые в открытом виде (принято по умолчанию для cookie). При включении маркеров в cookie должны приниматься меры защиты от кросс-сайтовой подмены.
Использование краткосрочных маркеров
Серверам следует выдавать краткосрочные (не более 1 часа) маркеры на предъявителя клиентам, работающим в браузерах и иных средах с возможностью утечки информации. Короткий срок действия маркеров смягчает последствия утечек.
Ограничение области действия маркеров.
Серверам следует выдавать маркеры на предъявителя с ограничением аудитории, позволяющие воспользоваться ими лишь ограниченному кругу клиентов.
Отказ от передачи маркеров в URL
Маркеры на предъявителя не следует передавать в URL страниц (например в параметрах строки query). Вместо этого следует помещать маркеры в заголовок или тело запроса HTTP, для которого обеспечивается защита конфиденциальности. Браузеры, web-серверы и другие программы могут не обеспечивать должный защиты URL в истории браузера, журнальных файлах web-сервера и других структурах данных. При передачи маркера на предъявителя в URL страницы злоумышленники могут украсть их из данных истории, файлов журнала и т. п.
6. Взаимодействие с IANA
6.1. Регистрация OAuth Access Token Type
Эта спецификация регистрирует указанный ниже тип маркера доступа в реестре OAuth Access Token Types [RFC6749].
6.1.1. Тип Bearer
Type name
Bearer
Additional Token Endpoint Response Parameters
(none)
HTTP Authentication Scheme(s)
Bearer
Change controller
IETF
Specification document(s)
RFC 6750
6.2. Регистрация ошибок расширения
Эта спецификация регистрирует приведённые ниже значения ошибок в реестре Oauth Extensions Error [RFC6749].
6.2.1. Ошибка invalid_request
Error name
invalid_request
Error usage location
Resource access error response — отклик на ошибку доступа к ресурсу
Related protocol extension
Bearer access token type — тип маркера доступа на предъявителя
Change controller
IETF
Specification document(s)
RFC 6750
6.2.2. Ошибка invalid_token
Error name
invalid_token
Error usage location
Resource access error response — отклик на ошибку доступа к ресурсу
Related protocol extension
Bearer access token type — тип маркера доступа на предъявителя
Change controller
IETF
Specification document(s)
RFC 6750
6.2.3. Ошибка insufficient_scope
Error name
insufficient_scope
Error usage location
Resource access error response — отклик на ошибку доступа к ресурсу
Related protocol extension
Bearer access token type — тип маркера доступа на предъявителя
Change controller
IETF
Specification document(s)
RFC 6750
7. Литература
7.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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.
[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.
[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, May 2008.
[RFC6265] Barth, A., «HTTP State Management Mechanism», RFC 6265, April 2011.
[RFC6749] Hardt, D., Ed., «The OAuth 2.0 Authorization Framework», RFC 6749, October 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 Recommendation REC-html401-19991224, December 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 Recommendation REC-webarch-20041215, December 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», Work in Progress7, October 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», December 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», April 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», June 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 Recordon и редактировал все последующие версии.
В рабочую группу 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.
Адреса авторов
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
Dick Hardt
Independent
EMail: dick.hardt@gmail.com
Перевод на русский язык
Николай Малых
1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.
3Transport Layer Security — защита на транспортом уровне.
4Augmented Backus-Naur Form — расширенная форма Бэкуса-Наура.
5В оригинале указано b64token. См. https://www.rfc-editor.org/errata/eid5335. Прим. перев.
6В оригинале эта строка ошибочно включает ;charset=UTF-8. См. https://www.rfc-editor.org/errata/eid6161. Прим. перев.