О документе
Internet Engineering Task Force (IETF) D. Hardt, ред.
Request for Comments: 6749 Microsoft
Заменяет: 5849 Октябрь 2012
Категория: Standards Track
ISSN: 2070-1721
Каркас авторизации OAuth 2.0
1. Введение
В традиционной клиент-серверной модели аутентификации клиент
запрашивает на сервере ресурс с ограниченным доступом (защищённый
ресурс), проходя аутентификацию на сервере с помощью учётных данных
владельца ресурса. Чтобы предоставить сторонним приложениям доступ
к ресурсам с ограниченным доступом, владелец ресурса передаёт свои
учётные данные стороннему участнику. Это создаёт ряд проблем
и ограничений:
o Сторонние приложения вынуждены хранить учётные данные владельца
ресурса для дальнейшего использования; обычно это пароль
в открытом виде.
o Серверы вынуждены поддерживать аутентификацию по паролю, несмотря
на присущие паролям недостатки с точки зрения безопасности.
o Сторонние приложения получают чрезмерно широкий доступ к защищённым
ресурсам владельца ресурса, лишая владельцев ресурсов какой-либо
возможности ограничить продолжительность доступа или разрешить
доступ лишь к ограниченному подмножеству ресурсов.
o Владельцы ресурсов не могут отозвать доступ у отдельного стороннего
участника, не отозвав доступ у всех сторонних участников, и для
этого должны изменить пароль стороннего участника.
o Компрометация любого стороннего приложения приводит к компрометации
пароля конечного пользователя и всех данных, защищённых этим
паролем.
OAuth решает эти проблемы, вводя уровень авторизации и отделяя роль
клиента от роли владельца ресурса. В OAuth клиент запрашивает доступ
к ресурсам, которыми управляет владелец ресурса и которые размещены
на сервере ресурсов, и получает набор учётных данных, отличный
от учётных данных владельца ресурса.
Вместо использования учётных данных владельца ресурса для доступа
к защищённым ресурсам клиент получает токен доступа — строку,
обозначающую определённую область действия, срок действия и другие
атрибуты доступа. Токены доступа выдаются сторонним клиентам сервером
авторизации с одобрения владельца ресурса. Клиент использует токен
доступа для доступа к защищённым ресурсам, размещённым на сервере
ресурсов.
Например, конечная пользовательница (владелец ресурса) может
предоставить службе печати (клиенту) доступ к своим защищённым
фотографиям, хранящимся в службе обмена фотографиями (сервере ресурсов),
не передавая службе печати свои имя пользователя и пароль. Вместо
этого она проходит аутентификацию непосредственно на сервере,
которому доверяет служба обмена фотографиями (сервере авторизации),
и этот сервер выдаёт службе печати учётные данные, предназначенные
для данного делегирования (токен доступа).
Эта спецификация предназначена для использования с HTTP ([RFC2616]).
Использование OAuth поверх любого протокола, отличного от HTTP,
выходит за рамки этой спецификации.
Протокол 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 определяет четыре роли:
владелец ресурса
Субъект, способный предоставлять доступ к защищённому ресурсу. Если владельцем ресурса является человек, его называют конечным пользователем.
сервер ресурсов
Сервер, на котором размещены защищённые ресурсы и который способен принимать запросы к защищённым ресурсам с использованием токенов доступа и отвечать на них.
клиент
Приложение, выполняющее запросы к защищённым ресурсам от имени владельца ресурса и с его разрешения. Термин «клиент» не подразумевает каких-либо конкретных характеристик реализации (например, того, выполняется ли приложение на сервере, настольном компьютере или других устройствах).
сервер авторизации
Сервер, выдающий клиенту токены доступа после успешной аутентификации владельца ресурса и получения разрешения.
Взаимодействие между сервером авторизации и сервером ресурсов выходит за рамки настоящей спецификации. Сервер авторизации может быть тем же сервером, что и сервер ресурсов, либо отдельным субъектом. Один сервер авторизации может выдавать токены доступа, принимаемые несколькими серверами ресурсов.
1.2. Последовательность взаимодействий протокола
+--------+ +---------------+
| |--(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, описывает взаимодействие четырёх ролей и включает следующие шаги:
(A) Клиент запрашивает разрешение у владельца ресурса. Запрос авторизации может направляться непосредственно владельцу ресурса (как показано на рисунке) или, что предпочтительнее, косвенно, через сервер авторизации в качестве посредника.
(B) Клиент получает авторизационное разрешение — учётные данные, представляющие разрешение владельца ресурса и выраженные с использованием одного из четырёх типов разрешений, определённых в настоящей спецификации, либо типа разрешения, определённого расширением. Тип авторизационного разрешения зависит от способа, которым клиент запрашивает авторизацию, и от типов, поддерживаемых сервером авторизации.
(C) Клиент запрашивает токен доступа, проходя аутентификацию на сервере авторизации и предъявляя авторизационное разрешение.
(D) Сервер авторизации аутентифицирует клиента и проверяет авторизационное разрешение; если оно действительно, сервер выдаёт токен доступа.
(E) Клиент запрашивает защищённый ресурс у сервера ресурсов и проходит аутентификацию, предъявляя токен доступа.
(F) Сервер ресурсов проверяет токен доступа и, если он действителен, обслуживает запрос.
Предпочтительный способ получения клиентом авторизационного разрешения от владельца ресурса (показанный на шагах (A) и (B)) — использование сервера авторизации в качестве посредника, как показано на рисунке 3 в разделе 4.1.
1.3. Авторизационное разрешение
Авторизационное разрешение — это учётные данные, представляющие разрешение владельца ресурса (на доступ к его защищённым ресурсам), которые клиент использует для получения токена доступа. Настоящая спецификация определяет четыре типа разрешений — код авторизации, неявное разрешение, учётные данные владельца ресурса с паролем и учётные данные клиента, — а также механизм расширения для определения дополнительных типов.
1.3.1. Код авторизации
Код авторизации получают, используя сервер авторизации в качестве посредника между клиентом и владельцем ресурса. Вместо непосредственного запроса разрешения у владельца ресурса клиент направляет владельца ресурса на сервер авторизации (через его пользовательский агент, определённый в [RFC2616]), который, в свою очередь, направляет владельца ресурса обратно к клиенту с кодом авторизации.
Прежде чем направить владельца ресурса обратно к клиенту с кодом авторизации, сервер авторизации аутентифицирует владельца ресурса и получает разрешение. Поскольку владелец ресурса проходит аутентификацию только на сервере авторизации, его учётные данные никогда не передаются клиенту.
Код авторизации обеспечивает несколько важных преимуществ с точки зрения безопасности, таких как возможность аутентификации клиента, а также передача токена доступа непосредственно клиенту без его прохождения через пользовательский агент владельца ресурса и возможного раскрытия другим лицам, включая самого владельца ресурса.
1.3.2. Неявное разрешение
Неявное разрешение представляет собой упрощённую последовательность взаимодействий с кодом авторизации, оптимизированную для клиентов, реализованных в браузере с использованием языка сценариев, такого как JavaScript. При неявной последовательности взаимодействий вместо кода авторизации клиенту непосредственно выдаётся токен доступа
(в результате предоставления разрешения владельцем ресурса). Этот тип разрешения является неявным, поскольку промежуточные учётные данные (такие как код авторизации) не выдаются (и впоследствии не используются для получения токена доступа).
При выдаче токена доступа в ходе взаимодействий с неявным разрешением сервер авторизации не аутентифицирует клиента. В некоторых случаях подлинность клиента можно проверить с помощью URI перенаправления, используемого для доставки токена доступа клиенту. Токен доступа может оказаться раскрыт владельцу ресурса или другим приложениям, имеющим доступ к пользовательскому агенту владельца ресурса.
Неявные разрешения повышают быстроту отклика и эффективность некоторых клиентов (например, клиента, реализованного в виде приложения, выполняемого в браузере), поскольку сокращают число обменов запросами и ответами, необходимых для получения токена доступа. Однако это удобство следует сопоставлять с последствиями использования неявных разрешений для безопасности, такими как описанные в разделах 10.3 и 10.16, особенно когда доступен тип разрешения с кодом авторизации.
1.3.3. Учётные данные владельца ресурса с паролем
Учётные данные владельца ресурса с паролем (то есть имя пользователя и пароль) могут использоваться непосредственно в качестве авторизационного разрешения для получения токена доступа. Эти учётные данные следует использовать только при высокой степени доверия между владельцем ресурса и клиентом (например, когда клиент является частью операционной системы устройства или приложением с высокими привилегиями) и при отсутствии других доступных типов авторизационных разрешений (таких как код авторизации).
Хотя этот тип разрешения требует непосредственного доступа клиента к учётным данным владельца ресурса, эти учётные данные используются для единственного запроса и обмениваются на токен доступа. Этот тип разрешения может устранить необходимость хранения клиентом учётных данных владельца ресурса для последующего использования благодаря обмену учётных данных на долгоживущий токен доступа или токен обновления.
1.3.4. Учётные данные клиента
Учётные данные клиента (или другие формы аутентификации клиента) могут использоваться в качестве авторизационного разрешения, когда область авторизации ограничена защищёнными ресурсами, находящимися под управлением клиента, либо защищёнными ресурсами, доступ к которым был предварительно согласован с сервером авторизации. Учётные данные клиента обычно используются в качестве авторизационного разрешения, когда клиент действует от собственного имени (клиент одновременно является владельцем ресурса) либо запрашивает доступ к защищённым ресурсам на основании разрешения, предварительно согласованного с сервером авторизации.
1.4. Токен доступа
Токены доступа — это учётные данные, используемые для доступа к защищённым ресурсам. Токен доступа представляет собой строку, обозначающую разрешение, выданное клиенту. Эта строка обычно непрозрачна для клиента. Токены представляют конкретные области и сроки доступа, предоставленного владельцем ресурса; соблюдение этих ограничений обеспечивают сервер ресурсов и сервер авторизации.
Токен может обозначать идентификатор, используемый для извлечения информации об авторизации, либо сам содержать информацию об авторизации в проверяемом виде (то есть представлять собой строку токена, состоящую из некоторых данных и подписи). Для использования токена клиенту могут потребоваться дополнительные аутентификационные учётные данные, которые выходят за рамки настоящей спецификации.
Токен доступа обеспечивает уровень абстракции, заменяя различные средства авторизации (например, имя пользователя и пароль) единым токеном, понятным серверу ресурсов. Эта абстракция позволяет выдавать токены доступа с более строгими ограничениями, чем авторизационное разрешение, использованное для их получения, а также избавляет сервер ресурсов от необходимости понимать широкий спектр методов аутентификации.
Токены доступа могут иметь различные форматы, структуры и способы использования (например, криптографические свойства) в зависимости от требований безопасности сервера ресурсов. Атрибуты токенов доступа и методы, используемые для доступа к защищённым ресурсам, выходят за рамки настоящей спецификации и определяются сопутствующими спецификациями, такими как [RFC6750].
1.5. Токен обновления
Токены обновления — это учётные данные, используемые для получения токенов доступа. Токены обновления выдаются клиенту сервером авторизации и используются для получения нового токена доступа, когда текущий токен доступа становится недействительным или истекает срок его действия, либо для получения дополнительных токенов доступа с той же или более узкой областью доступа (токены доступа могут иметь меньший срок действия и предоставлять меньше прав, чем разрешено владельцем ресурса). Выдача токена обновления необязательна и осуществляется по усмотрению сервера авторизации. Если сервер авторизации выдаёт токен обновления, тот включается в ответ при выдаче токена доступа (то есть на шаге (D) на рисунке 1).
Токен обновления представляет собой строку, обозначающую разрешение, предоставленное клиенту владельцем ресурса. Эта строка обычно непрозрачна для клиента. Токен обозначает идентификатор, используемый для извлечения
информации об авторизации. В отличие от токенов доступа, токены обновления предназначены для использования только с серверами авторизации и никогда не отправляются серверам ресурсов.
+--------+ +--------------------+
| |--(A)--------- Разрешение на авторизацию -------------->| |
| | | |
| |<-(B)-------------- Токен доступа ----------------------| |
| | и токен обновления | |
| | | |
| | +-------------+ | |
| |--(C)------ Токен доступа ---------->| | | |
| | | | | |
| |<-(D)--- Защищённый ресурс ----------| Сервер | | Сервер |
| Клиент | | ресурсов | | авторизации |
| |--(E)------ Токен доступа ---------->| | | |
| | | | | |
| |<-(F)- Ошибка недействительного токена| | | |
| | +-------------+ | |
| | | |
| |--(G)------------- Токен обновления ------------------->| |
| | | |
| |<-(H)-------------- Токен доступа ----------------------| |
+--------+ и необязательный токен обновления +--------------------+
Рисунок 2: Обновление токена доступа с истёкшим сроком действия
Процесс, показанный на рисунке 2, включает следующие шаги:
(A) Клиент запрашивает токен доступа, проходя аутентификацию на
сервере авторизации и предъявляя разрешение на авторизацию.
(B) Сервер авторизации аутентифицирует клиента и проверяет
разрешение на авторизацию и, если оно действительно, выдаёт
токен доступа и токен обновления.
(C) Клиент отправляет серверу ресурсов запрос к защищённому
ресурсу, предъявляя токен доступа.
(D) Сервер ресурсов проверяет токен доступа и, если он действителен,
обслуживает запрос.
(E) Шаги (C) и (D) повторяются до истечения срока действия токена
доступа. Если клиенту известно, что срок действия токена доступа
истёк, он переходит к шагу (G); в противном случае он отправляет
ещё один запрос к защищённому ресурсу.
(F) Поскольку токен доступа недействителен, сервер ресурсов
возвращает ошибку недействительного токена.
(G) Клиент запрашивает новый токен доступа, проходя аутентификацию
на сервере авторизации и предъявляя токен обновления.
Требования к аутентификации клиента зависят от типа клиента
и политик сервера авторизации.
(H) Сервер авторизации аутентифицирует клиента и проверяет токен
обновления и, если он действителен, выдаёт новый токен доступа
(и, необязательно, новый токен обновления).
Шаги (C), (D), (E) и (F) выходят за рамки этой спецификации,
как описано в разделе 7.
1.6. Версия TLS
Во всех случаях использования Transport Layer Security (TLS) в этой
спецификации подходящая версия (или версии) TLS будет меняться
со временем в зависимости от распространённости внедрения и известных
уязвимостей безопасности. На момент написания этого документа TLS
версии 1.2 [RFC5246] является самой новой версией, но её внедрение
весьма ограничено, и она может быть не вполне доступна для реализации.
TLS версии 1.0 [RFC2246] является наиболее широко внедрённой версией
и обеспечит наиболее широкую совместимость.
Реализации также МОГУТ (MAY) поддерживать дополнительные механизмы
безопасности транспортного уровня, удовлетворяющие их требованиям
безопасности.
1.7. Перенаправления HTTP
Эта спецификация широко использует перенаправления HTTP, при которых
клиент или сервер авторизации направляет пользовательский агент
владельца ресурса по другому адресу. Хотя примеры в этой спецификации
показывают использование кода состояния HTTP 302, допускается любой
другой доступный через пользовательский агент способ осуществления
такого перенаправления, и он считается деталью реализации.
1.8. Совместимость
OAuth 2.0 предоставляет многофункциональный каркас авторизации
с чётко определёнными свойствами безопасности. Однако, поскольку
этот каркас многофункционален, допускает широкое расширение
и содержит множество необязательных компонентов, сама по себе
эта спецификация, вероятно, приведёт к появлению широкого спектра
несовместимых реализаций.
Кроме того, эта спецификация оставляет несколько необходимых
компонентов частично или полностью неопределёнными (например,
регистрацию клиента, возможности сервера авторизации, обнаружение
конечных точек). Без
этих компонентов для обеспечения совместимости клиентов необходимо
вручную настраивать специально для конкретного сервера авторизации
и сервера ресурсов.
Этот каркас был разработан с явным расчётом на то, что в ходе
дальнейшей работы будут определены предписывающие профили
и расширения, необходимые для достижения полной совместимости
в масштабе Всемирной паутины.
1.9. Условные обозначения
Ключевые слова «ДОЛЖЕН (MUST)», «НЕ ДОЛЖЕН (MUST NOT)»,
«ДОЛЖЕН (REQUIRED)», «ДОЛЖЕН (SHALL)», «НЕ ДОЛЖЕН (SHALL NOT)»,
«СЛЕДУЕТ (SHOULD)», «НЕ СЛЕДУЕТ (SHOULD NOT)»,
«СЛЕДУЕТ (RECOMMENDED)», «МОЖЕТ (MAY)» и
«НЕОБЯЗАТЕЛЬНО (OPTIONAL)» в этой спецификации следует понимать
так, как описано в [RFC2119].
В этой спецификации используется нотация расширенной формы
Бэкуса — Наура (ABNF) из [RFC5234]. Кроме того, правило URI-reference
заимствовано из «Uniform Resource Identifier (URI): Generic Syntax»
[RFC3986].
Некоторые термины, относящиеся к безопасности, следует понимать
в смысле, определённом в [RFC4949]. К таким терминам относятся,
помимо прочих, «атака», «аутентификация», «авторизация»,
«сертификат», «конфиденциальность», «учётные данные», «шифрование»,
«идентичность», «подписывать», «подпись», «доверие», «проверять
действительность» (validate) и «проверять» (verify).
Если не указано иное, все имена и значения параметров протокола
чувствительны к регистру.
2. Регистрация клиента
Прежде чем начать выполнение протокола, клиент регистрируется
на сервере авторизации. Способы регистрации клиента на сервере
авторизации выходят за рамки этой спецификации, но обычно
предусматривают взаимодействие конечного пользователя с формой
регистрации HTML.
Регистрация клиента не требует непосредственного взаимодействия
между клиентом и сервером авторизации. Если сервер авторизации
поддерживает такую возможность, регистрация может опираться
на другие способы установления доверия и получения необходимых
свойств клиента (например, URI перенаправления, типа клиента).
Например, регистрация может осуществляться с использованием
утверждения, выпущенного самим клиентом или третьей стороной,
либо посредством обнаружения клиента сервером авторизации
с использованием доверенного канала.
При регистрации клиента разработчик клиента ДОЛЖЕН (SHALL):
o указать тип клиента, как описано в разделе 2.1;
o предоставить URI перенаправления своего клиента, как описано
в разделе 3.1.2; и
o включить любую другую информацию, требуемую сервером авторизации
(например, название приложения, веб-сайт, описание, изображение
логотипа, принятие юридических условий).
2.1. Типы клиентов
OAuth определяет два типа клиентов в зависимости от их способности
безопасно проходить аутентификацию на сервере авторизации
(то есть способности сохранять конфиденциальность своих
учётных данных клиента):
конфиденциальный
Клиенты, способные сохранять конфиденциальность своих учётных
данных (например, клиент, реализованный на защищённом сервере
с ограниченным доступом к учётным данным клиента), либо способные
безопасно проходить аутентификацию клиента другими средствами.
публичный
Клиенты, неспособные сохранять конфиденциальность своих учётных
данных (например, клиенты, выполняющиеся на устройстве,
используемом владельцем ресурса, такие как установленное нативное
приложение или приложение на основе веб-браузера), и неспособные
безопасно проходить аутентификацию клиента какими-либо другими
средствами.
Отнесение клиента к определённому типу основано на том, как сервер
авторизации определяет безопасную аутентификацию, и на допустимых
для него уровнях раскрытия учётных данных клиента. Серверу
авторизации НЕ СЛЕДУЕТ (SHOULD NOT) делать предположения о типе
клиента.
Клиент может быть реализован как распределённый набор компонентов,
каждый из которых имеет свой тип клиента и контекст безопасности
(например, распределённый клиент с конфиденциальным серверным
компонентом и публичным браузерным компонентом). Если сервер
авторизации не поддерживает таких клиентов или не предоставляет
указаний относительно их регистрации, клиенту СЛЕДУЕТ (SHOULD)
регистрировать каждый компонент как отдельного клиента.
Эта спецификация была разработана с учётом следующих профилей
клиентов:
веб-приложение
Веб-приложение — это конфиденциальный клиент, работающий
на веб-сервере. Владельцы ресурсов обращаются к клиенту через
пользовательский интерфейс HTML, отображаемый пользовательским
агентом на устройстве, используемом владельцем ресурса. Учётные
данные клиента, а также любой выданный клиенту токен доступа
хранятся на веб-сервере, не раскрываются владельцу ресурса
и недоступны ему.
приложение на основе пользовательского агента
Приложение на основе пользовательского агента — это публичный
клиент, код которого загружается с веб-сервера и выполняется
внутри пользовательского агента (например, веб-браузера)
на устройстве, используемом владельцем ресурса. Данные протокола
и учётные данные легко доступны (и часто видимы) владельцу
ресурса. Поскольку такие приложения находятся внутри
пользовательского агента, при запросе авторизации они могут
беспрепятственно использовать его возможности.
нативное приложение
Нативное приложение — это публичный клиент, установленный
и выполняющийся на устройстве, используемом владельцем ресурса.
Данные протокола и учётные данные доступны владельцу ресурса.
Предполагается, что любые учётные данные для аутентификации
клиента, включённые в приложение, могут быть извлечены.
С другой стороны, динамически выдаваемые учётные данные, такие
как токены доступа или токены обновления, могут получать
приемлемый уровень защиты. Как минимум, эти учётные данные
защищены от враждебных серверов, с которыми приложение может
взаимодействовать. На некоторых платформах эти учётные данные
могут быть защищены от других приложений, находящихся
на том же устройстве.
2.2. Идентификатор клиента
Сервер авторизации выдаёт зарегистрированному клиенту идентификатор
клиента — уникальную строку, представляющую регистрационную
информацию, предоставленную клиентом. Идентификатор клиента
не является секретом; он раскрывается владельцу ресурса и
НЕ ДОЛЖЕН (MUST NOT) использоваться сам по себе для аутентификации
клиента. Идентификатор клиента уникален в пределах сервера
авторизации.
Размер строки идентификатора клиента в этой спецификации
не определён. Клиенту следует избегать предположений о размере
идентификатора. Серверу авторизации СЛЕДУЕТ (SHOULD) документировать
размер любого выдаваемого им идентификатора.
2.3. Аутентификация клиента
Если тип клиента — конфиденциальный, клиент и сервер авторизации
устанавливают метод аутентификации клиента, соответствующий
требованиям безопасности сервера авторизации. Сервер авторизации
МОЖЕТ (MAY) принимать любую форму аутентификации клиента,
удовлетворяющую его требованиям безопасности.
Конфиденциальным клиентам обычно выдаётся (либо они устанавливают)
набор учётных данных клиента, используемых для аутентификации
на сервере авторизации (например, пароль, пара открытого
и закрытого ключей).
Сервер авторизации МОЖЕТ (MAY) установить метод аутентификации
клиента с публичными клиентами. Однако сервер авторизации
НЕ ДОЛЖЕН (MUST NOT) полагаться на аутентификацию публичного клиента
для идентификации клиента.
Клиент НЕ ДОЛЖЕН (MUST NOT) использовать более одного метода
аутентификации в каждом запросе.
2.3.1. Пароль клиента
Клиенты, располагающие паролем клиента, МОГУТ (MAY) использовать
схему аутентификации HTTP Basic, определённую в [RFC2617],
для аутентификации на сервере авторизации. Идентификатор клиента
кодируется с использованием алгоритма кодирования
«application/x-www-form-urlencoded» согласно приложению B,
и закодированное значение используется в качестве имени
пользователя; пароль клиента кодируется с использованием
того же алгоритма и используется в качестве пароля. Сервер
авторизации ДОЛЖЕН (MUST) поддерживать схему аутентификации HTTP Basic
для аутентификации клиентов, которым был выдан пароль клиента.
Например (дополнительные переносы строк служат только для наглядности):
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
В качестве альтернативы сервер авторизации МОЖЕТ (MAY) поддерживать
включение учётных данных клиента в тело запроса с использованием
следующих параметров:
client_id
ДОЛЖЕН (REQUIRED) присутствовать. Идентификатор клиента,
выданный клиенту в процессе регистрации, описанном в разделе 2.2.
client_secret
ДОЛЖЕН (REQUIRED) присутствовать. Секрет клиента. Клиент
МОЖЕТ (MAY) опустить этот параметр, если секрет клиента
является пустой строкой.
Включать учётные данные клиента в тело запроса с помощью этих двух
параметров НЕ СЛЕДУЕТ (NOT RECOMMENDED); их использование СЛЕДУЕТ (SHOULD)
ограничить клиентами, неспособными напрямую использовать схему
аутентификации HTTP Basic (или другие схемы HTTP-аутентификации на основе
пароля). Параметры могут передаваться только в теле запроса и
НЕ ДОЛЖНЫ (MUST NOT) включаться в 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
Сервер авторизации ДОЛЖЕН (MUST) требовать использования TLS, как описано
в разделе 1.6, при отправке запросов с аутентификацией по паролю.
Поскольку этот метод аутентификации клиента предусматривает использование
пароля, сервер авторизации ДОЛЖЕН (MUST) защищать любую использующую его
конечную точку от атак методом полного перебора.
2.3.2. Другие методы аутентификации
Сервер авторизации МОЖЕТ (MAY) поддерживать любую подходящую схему
HTTP-аутентификации, соответствующую его требованиям безопасности.
При использовании других методов аутентификации сервер авторизации
ДОЛЖЕН (MUST) определить соответствие между идентификатором клиента
(регистрационной записью) и схемой аутентификации.
2.4. Незарегистрированные клиенты
Эта спецификация не исключает использования незарегистрированных
клиентов. Однако использование таких клиентов выходит за рамки этой
спецификации и требует дополнительного анализа безопасности и оценки
его влияния на совместимость.
3. Конечные точки протокола
В процессе авторизации используются две конечные точки сервера
авторизации (HTTP-ресурсы):
o Конечная точка авторизации — используется клиентом для получения
авторизации от владельца ресурса посредством перенаправления
пользовательского агента.
o Конечная точка токенов — используется клиентом для обмена разрешения
на доступ на токен доступа, обычно с аутентификацией клиента.
А также одна конечная точка клиента:
o Конечная точка перенаправления — используется сервером авторизации
для возврата клиенту ответов, содержащих учётные данные авторизации,
через пользовательский агент владельца ресурса.
Не каждый тип разрешения на доступ использует обе конечные точки.
Дополнительные типы разрешений на доступ МОГУТ (MAY) при необходимости
определять дополнительные конечные точки.
3.1. Конечная точка авторизации
Конечная точка авторизации используется для взаимодействия с владельцем
ресурса и получения разрешения на доступ. Сервер авторизации
ДОЛЖЕН (MUST) сначала удостовериться в личности владельца ресурса.
Способ, которым сервер авторизации аутентифицирует владельца ресурса
(например, вход по имени пользователя и паролю, сеансовые cookie),
выходит за рамки этой спецификации.
Средства, с помощью которых клиент получает адрес конечной точки
авторизации, выходят за рамки этой спецификации, однако этот адрес
обычно указывается в документации сервиса.
URI конечной точки МОЖЕТ (MAY) содержать компонент запроса
([RFC3986], раздел 3.4) в формате "application/x-www-form-urlencoded"
(согласно приложению B), который ДОЛЖЕН (MUST) сохраняться при добавлении
дополнительных параметров запроса. URI конечной точки
НЕ ДОЛЖЕН (MUST NOT) содержать компонент фрагмента.
Поскольку запросы к конечной точке авторизации приводят к аутентификации
пользователя и передаче учётных данных в открытом виде (в HTTP-ответе),
сервер авторизации ДОЛЖЕН (MUST) требовать использования TLS, как описано
в разделе 1.6, при отправке запросов к конечной точке авторизации.
Сервер авторизации ДОЛЖЕН (MUST) поддерживать использование HTTP-метода
"GET" [RFC2616] для конечной точки авторизации и МОЖЕТ (MAY) также
поддерживать использование метода "POST".
Параметры, переданные без значения, ДОЛЖНЫ (MUST) обрабатываться так,
как если бы они отсутствовали в запросе. Сервер авторизации
ДОЛЖЕН (MUST) игнорировать нераспознанные параметры запроса. Параметры
запроса и ответа НЕ ДОЛЖНЫ (MUST NOT) включаться более одного раза.
3.1.1. Тип ответа
Конечная точка авторизации используется в процессах получения разрешения
на доступ с кодом авторизации и неявного разрешения на доступ. Клиент
сообщает серверу авторизации желаемый тип разрешения на доступ с помощью
следующего параметра:
response_type
ДОЛЖЕН (REQUIRED) присутствовать. Значение ДОЛЖНО (MUST) быть одним из
следующих: "code" для запроса кода авторизации, как описано
в разделе 4.1.1; "token" для запроса токена доступа (неявное
разрешение на доступ), как описано в разделе 4.2.1; либо
зарегистрированное значение расширения, как описано в разделе 8.4.
Дополнительные типы ответа МОГУТ (MAY) содержать список значений,
разделённых пробелами (%x20), в котором порядок значений не имеет
значения (например, тип ответа "a b" совпадает с "b a"). Значение таких
составных типов ответа определяется соответствующими спецификациями.
Если в запросе авторизации отсутствует параметр "response_type" или
тип ответа не распознан, сервер авторизации ДОЛЖЕН (MUST) вернуть
ответ об ошибке, как описано в разделе 4.1.2.1.
3.1.2. Конечная точка перенаправления
После завершения взаимодействия с владельцем ресурса сервер авторизации
направляет пользовательский агент владельца ресурса обратно к клиенту.
Сервер авторизации перенаправляет пользовательский агент на конечную
точку перенаправления клиента, ранее согласованную с сервером авторизации
в процессе регистрации клиента или при выполнении запроса авторизации.
URI конечной точки перенаправления ДОЛЖЕН (MUST) быть абсолютным URI,
как определено в [RFC3986], раздел 4.3. URI конечной точки МОЖЕТ (MAY)
содержать компонент запроса ([RFC3986], раздел 3.4) в формате
"application/x-www-form-urlencoded" (согласно приложению B), который
ДОЛЖЕН (MUST) сохраняться при добавлении дополнительных параметров
запроса. URI конечной точки НЕ ДОЛЖЕН (MUST NOT) содержать компонент
фрагмента.
3.1.2.1. Конфиденциальность запросов к конечной точке
Конечной точке перенаправления СЛЕДУЕТ (SHOULD) требовать использования
TLS, как описано в разделе 1.6, когда запрошенный тип ответа — "code"
или "token", либо когда запрос перенаправления приведёт к передаче
конфиденциальных учётных данных по открытой сети. Эта спецификация
не устанавливает обязательного использования TLS, поскольку на момент
её написания требование развёртывания TLS на стороне клиентов
представляло собой существенное препятствие для многих разработчиков
клиентов. Если TLS недоступен, серверу авторизации СЛЕДУЕТ (SHOULD)
предупредить владельца ресурса о небезопасной конечной точке до
перенаправления (например, показать сообщение во время запроса
авторизации).
Отсутствие защиты на транспортном уровне может серьёзно повлиять на
безопасность клиента и защищённых ресурсов, к которым ему разрешён
доступ. Использование защиты на транспортном уровне особенно важно,
когда клиент использует процесс авторизации как форму делегированной
аутентификации конечного пользователя (например, сервис входа через
стороннего поставщика).
3.1.2.2. Требования к регистрации
Сервер авторизации ДОЛЖЕН (MUST) требовать регистрации конечной точки
перенаправления от следующих клиентов:
o Публичные клиенты.
o Конфиденциальные клиенты, использующие неявный тип разрешения
на доступ.
Серверу авторизации СЛЕДУЕТ (SHOULD) требовать от всех клиентов
регистрации их конечной точки перенаправления до использования конечной
точки авторизации.
Серверу авторизации СЛЕДУЕТ (SHOULD) требовать от клиента предоставления
полного URI перенаправления (клиент МОЖЕТ (MAY) использовать параметр
запроса "state" для настройки, индивидуальной для каждого запроса).
Если невозможно потребовать регистрации полного URI перенаправления,
серверу авторизации СЛЕДУЕТ (SHOULD) требовать регистрации схемы,
компонента authority и пути URI (позволяя клиенту при запросе авторизации
динамически изменять только компонент запроса URI перенаправления).
Сервер авторизации МОЖЕТ (MAY) разрешить клиенту зарегистрировать
несколько конечных точек перенаправления.
Отсутствие требования регистрации URI перенаправления может позволить
злоумышленнику использовать конечную точку авторизации в качестве
открытого перенаправителя, как описано в разделе 10.15.
3.1.2.3. Динамическая настройка
Если зарегистрировано несколько URI перенаправления, зарегистрирована
только часть URI перенаправления либо не зарегистрировано ни одного
URI перенаправления, клиент ДОЛЖЕН (MUST) включать URI перенаправления
в запрос авторизации с помощью параметра запроса "redirect_uri".
Когда URI перенаправления включён в запрос авторизации, сервер
авторизации ДОЛЖЕН (MUST) сравнить полученное значение по меньшей мере
с одним из зарегистрированных URI перенаправления (или компонентов URI)
и установить соответствие согласно [RFC3986], раздел 6, если какие-либо
URI перенаправления были зарегистрированы. Если регистрация клиента
включала полный URI перенаправления, сервер авторизации ДОЛЖЕН (MUST)
сравнить эти два URI посредством простого сравнения строк, как определено
в [RFC3986], раздел 6.2.1.
3.1.2.4. Недопустимая конечная точка
Если запрос авторизации не проходит проверку из-за отсутствующего,
недопустимого или несовпадающего URI перенаправления, серверу авторизации
СЛЕДУЕТ (SHOULD) сообщить владельцу ресурса об ошибке, и сервер
НЕ ДОЛЖЕН (MUST NOT) автоматически перенаправлять пользовательский агент
на недопустимый URI перенаправления.
3.1.2.5. Содержимое конечной точки
Запрос перенаправления к конечной точке клиента обычно приводит к ответу
в виде HTML-документа, обрабатываемого пользовательским агентом. Если
HTML-ответ выдаётся непосредственно в результате запроса перенаправления,
любой сценарий, включённый в HTML-документ, будет выполняться с полным
доступом к URI перенаправления и содержащимся в нём учётным данным.
Клиенту НЕ СЛЕДУЕТ (SHOULD NOT) включать какие-либо сторонние сценарии
(например, стороннюю аналитику, социальные плагины, рекламные сети)
в ответ конечной точки перенаправления. Вместо этого ему СЛЕДУЕТ (SHOULD)
извлечь учётные данные из URI и снова перенаправить пользовательский агент
на другую конечную точку, не раскрывая учётные данные (в URI или где-либо
ещё). Если сторонние сценарии включены, клиент ДОЛЖЕН (MUST) обеспечить,
чтобы его собственные сценарии (используемые для извлечения учётных данных
из URI и их удаления из него) выполнялись первыми.
3.2. Конечная точка токенов
Конечная точка токенов используется клиентом для получения токена доступа
путём предъявления своего разрешения на доступ или токена обновления.
Конечная точка токенов используется со всеми разрешениями на доступ,
кроме неявного типа разрешения на доступ (поскольку токен доступа
выдаётся непосредственно).
Средства, с помощью которых клиент получает адрес конечной точки токенов,
выходят за рамки этой спецификации, однако этот адрес обычно указывается
в документации сервиса.
URI конечной точки МОЖЕТ (MAY) содержать компонент запроса
([RFC3986], раздел 3.4) в формате "application/x-www-form-urlencoded"
(согласно приложению B), который ДОЛЖЕН (MUST) сохраняться при добавлении
дополнительных параметров запроса. URI конечной точки
НЕ ДОЛЖЕН (MUST NOT) содержать компонент фрагмента.
Поскольку запросы к конечной точке токенов приводят к передаче учётных
данных в открытом виде (в HTTP-запросе и ответе), сервер авторизации
ДОЛЖЕН (MUST) требовать использования TLS, как описано в разделе 1.6,
при отправке запросов к конечной точке токенов.
Клиент ДОЛЖЕН (MUST) использовать HTTP-метод "POST" при выполнении
запросов токена доступа.
Параметры, переданные без значения, ДОЛЖНЫ (MUST) обрабатываться так,
как если бы они отсутствовали в запросе. Сервер авторизации
ДОЛЖЕН (MUST) игнорировать нераспознанные параметры запроса. Параметры
запроса и ответа НЕ ДОЛЖНЫ (MUST NOT) включаться более одного раза.
3.2.1. Аутентификация клиента
Конфиденциальные клиенты или другие клиенты, которым выданы учётные данные
клиента, ДОЛЖНЫ (MUST) аутентифицироваться на сервере авторизации, как
описано в разделе 2.3, при выполнении запросов к конечной точке токенов.
Аутентификация клиента используется для:
o Обеспечения привязки токенов обновления и кодов авторизации к клиенту,
которому они были выданы. Аутентификация клиента критически важна,
когда код авторизации передаётся на конечную точку перенаправления
по незащищённому каналу или когда URI перенаправления зарегистрирован
не полностью.
o Восстановления после компрометации клиента путём отключения клиента
или изменения его учётных данных, тем самым предотвращая
злоупотребление украденными токенами обновления со стороны
злоумышленника. Изменить один набор учётных данных клиента значительно
быстрее, чем отозвать весь набор токенов обновления.
o Реализации передовых практик управления аутентификацией, требующих
периодической ротации учётных данных. Ротация всего набора токенов
обновления может быть затруднительной, тогда как ротация одного набора
учётных данных клиента значительно проще.
Клиент МОЖЕТ (MAY) использовать параметр запроса "client_id" для своей
идентификации при отправке запросов к конечной точке токенов. В запросе
к конечной точке токенов со значением "authorization_code" параметра
"grant_type" неаутентифицированный клиент ДОЛЖЕН (MUST) передать свой
"client_id", чтобы предотвратить непреднамеренное принятие им кода,
предназначенного для клиента с другим "client_id". Это защищает клиента
от подмены кода аутентификации. (Это не обеспечивает дополнительной
безопасности защищённого ресурса.)
3.3. Область действия токена доступа
Конечные точки авторизации и выдачи токенов позволяют клиенту указывать область действия запрашиваемого доступа с помощью параметра запроса "scope". В свою очередь, сервер авторизации использует параметр ответа "scope", чтобы сообщить клиенту область действия выданного токена доступа.
Значение параметра scope выражается в виде списка строк, разделённых пробелами и чувствительных к регистру. Эти строки определяются сервером авторизации. Если значение содержит несколько строк, разделённых пробелами, их порядок не имеет значения, а каждая строка добавляет дополнительный диапазон доступа к запрашиваемой области действия.
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
Сервер авторизации МОЖЕТ (MAY) полностью или частично игнорировать запрошенную клиентом область действия на основании политики сервера авторизации или указаний владельца ресурса. Если область действия выданного токена доступа отличается от запрошенной клиентом, сервер авторизации ДОЛЖЕН (MUST) включить параметр ответа "scope", чтобы сообщить клиенту фактически предоставленную область действия.
Если клиент опускает параметр scope при запросе авторизации, сервер авторизации ДОЛЖЕН (MUST) либо обработать запрос с использованием заранее определённого значения по умолчанию, либо отклонить запрос, указав недопустимую область действия. Серверу авторизации СЛЕДУЕТ (SHOULD) документировать свои требования к области действия и значение по умолчанию (если оно определено).
4. Получение авторизации
Чтобы запросить токен доступа, клиент получает авторизацию от владельца ресурса. Авторизация выражается в форме предоставления авторизации, которое клиент использует для запроса токена доступа. OAuth определяет четыре типа предоставления авторизации: код авторизации, неявное предоставление, учётные данные владельца ресурса с паролем и учётные данные клиента. Он также предоставляет механизм расширения для определения дополнительных типов предоставления авторизации.
4.1. Предоставление авторизации с использованием кода авторизации
Тип предоставления авторизации с использованием кода авторизации применяется для получения как токенов доступа, так и токенов обновления и оптимизирован для конфиденциальных клиентов. Поскольку этот процесс основан на перенаправлениях, клиент должен быть способен взаимодействовать с пользовательским агентом владельца ресурса (обычно веб-браузером) и принимать входящие запросы (посредством перенаправления) от сервера авторизации.
+------------------+
| Владелец |
| ресурса |
| |
+------------------+
^
|
(B)
+--------|---------+ Идентификатор клиента +------------------+
| -+----(A)-- и URI перенаправления -->| |
| Пользовательский | | Сервер |
| агент -+----(B)-- Пользователь ----------->| авторизации |
| | аутентифицируется | |
| -+----(C)-- Код авторизации --------<| |
+--|----------|----+ +------------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+------------------+ | |
| |>---(D)-- Код авторизации -------------' |
| Клиент | и URI перенаправления |
| | |
| |<---(E)----- Токен доступа --------------------'
+------------------+ (с необязательным токеном обновления)
Примечание: линии, иллюстрирующие шаги (A), (B) и (C), разделены на две части, поскольку проходят через пользовательский агент.
Рисунок 3: Процесс с использованием кода авторизации
Процесс, показанный на рисунке 3, включает следующие шаги:
(A) Клиент инициирует процесс, направляя пользовательский агент владельца ресурса к конечной точке авторизации. Клиент включает свой идентификатор клиента, запрашиваемую область действия, локальное состояние и URI перенаправления, на который сервер авторизации направит пользовательский агент обратно после предоставления доступа (или отказа в нём).
(B) Сервер авторизации аутентифицирует владельца ресурса (через пользовательский агент) и устанавливает, удовлетворяет ли владелец ресурса запрос клиента на доступ или отклоняет его.
(C) При условии, что владелец ресурса предоставляет доступ, сервер авторизации перенаправляет пользовательский агент обратно к клиенту, используя URI перенаправления, предоставленный ранее (в запросе или при регистрации клиента). URI перенаправления включает код авторизации и любое локальное состояние, ранее предоставленное клиентом.
(D) Клиент запрашивает токен доступа у конечной точки выдачи токенов сервера авторизации, включая код авторизации, полученный на предыдущем шаге. При выполнении запроса клиент проходит аутентификацию на сервере авторизации. Для проверки клиент включает URI перенаправления, использованный для получения кода авторизации.
(E) Сервер авторизации аутентифицирует клиента, проверяет код авторизации и удостоверяется, что полученный URI перенаправления совпадает с URI, использованным для перенаправления клиента на шаге (C). Если проверка пройдена, сервер авторизации возвращает в ответе токен доступа и, необязательно, токен обновления.
4.1.1. Запрос авторизации
Клиент формирует URI запроса, добавляя следующие параметры в компонент запроса URI конечной точки авторизации с использованием формата "application/x-www-form-urlencoded" согласно приложению B:
response_type
ДОЛЖЕН (REQUIRED) присутствовать. Значение ДОЛЖНО (MUST) быть установлено в "code".
client_id
ДОЛЖЕН (REQUIRED) присутствовать. Идентификатор клиента, описанный в разделе 2.2.
redirect_uri
НЕОБЯЗАТЕЛЬНО (OPTIONAL). Как описано в разделе 3.1.2.
scope
НЕОБЯЗАТЕЛЬНО (OPTIONAL). Область действия запрашиваемого доступа, описанная в разделе 3.3.
state
СЛЕДУЕТ (RECOMMENDED) включать. Непрозрачное значение, используемое клиентом для сохранения состояния между запросом и обратным вызовом. Сервер авторизации включает это значение при перенаправлении пользовательского агента обратно к клиенту. Параметр СЛЕДУЕТ (SHOULD) использовать для предотвращения подделки межсайтовых запросов, как описано в разделе 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. Ответ на запрос авторизации
Если владелец ресурса удовлетворяет запрос на доступ, сервер авторизации выдаёт код авторизации и доставляет его клиенту, добавляя следующие параметры в компонент запроса URI перенаправления с использованием формата "application/x-www-form-urlencoded" согласно приложению B:
code
ДОЛЖЕН (REQUIRED) присутствовать. Код авторизации, сгенерированный сервером авторизации. Срок действия кода авторизации ДОЛЖЕН (MUST) истекать вскоре после его выдачи, чтобы снизить риск утечек. СЛЕДУЕТ (RECOMMENDED) ограничивать максимальный срок действия кода авторизации 10 минутами. Клиент НЕ ДОЛЖЕН (MUST NOT) использовать код авторизации
более одного раза. Если код авторизации используется более одного раза, сервер авторизации ДОЛЖЕН (MUST) отклонить запрос, и ему СЛЕДУЕТ (SHOULD) отозвать (когда это возможно) все токены, ранее выданные на основании этого кода авторизации. Код авторизации привязан к идентификатору клиента и URI перенаправления.
state
ДОЛЖЕН (REQUIRED) присутствовать, если параметр "state" присутствовал в запросе авторизации клиента. В точности то значение, которое было получено от клиента.
Например, сервер авторизации перенаправляет пользовательский агент, отправляя следующий HTTP-ответ:
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
Клиент ДОЛЖЕН (MUST) игнорировать нераспознанные параметры ответа. Данная спецификация не определяет размер строки кода авторизации. Клиенту следует избегать предположений о размерах значений кода. Серверу авторизации СЛЕДУЕТ (SHOULD) документировать размер любого выдаваемого им значения.
4.1.2.1. Ответ об ошибке
Если запрос завершается неудачей из-за отсутствующего, недопустимого или несовпадающего URI перенаправления либо если идентификатор клиента отсутствует или недопустим, серверу авторизации СЛЕДУЕТ (SHOULD) сообщить владельцу ресурса об ошибке, и сервер авторизации НЕ ДОЛЖЕН (MUST NOT) автоматически перенаправлять пользовательский агент на недопустимый URI перенаправления.
Если владелец ресурса отклоняет запрос на доступ или запрос завершается неудачей по причинам, отличным от отсутствующего или недопустимого URI перенаправления, сервер авторизации сообщает об этом клиенту, добавляя следующие параметры в компонент запроса URI перенаправления с использованием формата "application/x-www-form-urlencoded" согласно приложению B:
error
ДОЛЖЕН (REQUIRED) присутствовать. Один код ошибки в 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" НЕ ДОЛЖНЫ (MUST NOT) включать символы вне набора %x20-21 / %x23-5B / %x5D-7E.
error_description
НЕОБЯЗАТЕЛЬНО (OPTIONAL). Человекочитаемый текст в ASCII [USASCII], предоставляющий дополнительную информацию, которая помогает разработчику клиента понять произошедшую ошибку.
Значения параметра "error_description" НЕ ДОЛЖНЫ (MUST NOT) включать символы вне набора %x20-21 / %x23-5B / %x5D-7E.
error_uri
НЕОБЯЗАТЕЛЬНО (OPTIONAL). URI, идентифицирующий человекочитаемую веб-страницу с информацией об ошибке и используемый для предоставления разработчику клиента дополнительной информации об ошибке.
Значения параметра "error_uri" ДОЛЖНЫ (MUST) соответствовать синтаксису URI-reference и, следовательно, НЕ ДОЛЖНЫ (MUST NOT) включать символы вне набора %x21 / %x23-5B / %x5D-7E.
state
ДОЛЖЕН (REQUIRED) присутствовать, если параметр "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
ДОЛЖЕН (REQUIRED) присутствовать. Значение ДОЛЖНО (MUST) быть установлено в "authorization_code".
code
ДОЛЖЕН (REQUIRED) присутствовать. Код авторизации, полученный от сервера авторизации.
redirect_uri
ДОЛЖЕН присутствовать (REQUIRED), если параметр "redirect_uri"
был включён в запрос авторизации, как описано в разделе 4.1.1,
и их значения ДОЛЖНЫ (MUST) быть одинаковыми.
client_id
ДОЛЖЕН присутствовать (REQUIRED), если клиент не проходит
аутентификацию на сервере авторизации, как описано в разделе 3.2.1.
Если тип клиента — конфиденциальный или клиенту были выданы учётные
данные клиента (либо для него установлены другие требования к
аутентификации), клиент ДОЛЖЕН (MUST) пройти аутентификацию на сервере
авторизации, как описано в разделе 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
Сервер авторизации ДОЛЖЕН (MUST):
o требовать аутентификации клиента для конфиденциальных клиентов или
для любого клиента, которому были выданы учётные данные клиента
(либо для которого установлены другие требования к аутентификации),
o аутентифицировать клиента, если в запрос включена аутентификация
клиента,
o удостовериться, что код авторизации был выдан аутентифицированному
конфиденциальному клиенту, либо, если клиент является публичным,
удостовериться, что код был выдан клиенту, указанному в "client_id"
в запросе,
o проверить действительность кода авторизации и
o удостовериться, что параметр "redirect_uri" присутствует, если
параметр "redirect_uri" был включён в первоначальный запрос
авторизации, как описано в разделе 4.1.1, и, если он включён,
удостовериться, что их значения одинаковы.
4.1.4. Ответ с токеном доступа
Если запрос токена доступа действителен и авторизован, сервер
авторизации выдаёт токен доступа и необязательный токен обновления,
как описано в разделе 5.1. Если аутентификация клиента в запросе
завершилась неудачно или является недействительной, сервер авторизации
возвращает ответ об ошибке, как описано в разделе 5.2.
Пример успешного ответа:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
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.
Поскольку этот процесс основан на перенаправлениях, клиент должен
быть способен взаимодействовать с пользовательским агентом владельца
ресурса (обычно веб-браузером) и получать входящие запросы
(посредством перенаправления) от сервера авторизации.
В отличие от типа предоставления полномочий с кодом авторизации,
при котором клиент выполняет отдельные запросы на авторизацию и на
получение токена доступа, здесь клиент получает токен доступа в
результате запроса авторизации.
Неявный тип предоставления полномочий не включает аутентификацию
клиента и опирается на присутствие владельца ресурса и регистрацию
URI перенаправления. Поскольку токен доступа включается в URI
перенаправления в закодированном виде, он может стать доступным
владельцу ресурса и другим приложениям на том же устройстве.
+------------------+
| Владелец |
| ресурса |
| |
+------------------+
^
|
(B)
+--------|---------+ +------------------+
| -+---(A)--- Идентификатор клиента --------->| |
| | и URI перенаправления | Сервер |
| Пользовательский | | авторизации |
| агент -|---(B)--- Пользователь проходит --------->| |
| | аутентификацию | |
| |<--(C)--- URI перенаправления ------------<| |
| | с токеном доступа +------------------+
| | во фрагменте
| | +------------------+
| |---(D)--- URI перенаправления ----------->| Размещённый |
| | без фрагмента | в вебе |
| | | ресурс клиента |
| (F) |<--(E)--------- Сценарий -----------------<| |
| | +------------------+
+-|----------------+
| |
(A) (G) Токен доступа
| |
^ v
+---------+
| |
| Клиент |
| |
+---------+
Примечание: линии, иллюстрирующие шаги (A) и (B), разделены на две
части в местах прохождения через пользовательский агент.
Рисунок 4: Процесс неявного предоставления полномочий
Процесс, показанный на рисунке 4, включает следующие шаги:
(A) Клиент инициирует процесс, направляя пользовательский агент
владельца ресурса к конечной точке авторизации. Клиент включает
свой идентификатор клиента, запрашиваемую область доступа,
локальное состояние и URI перенаправления, на который сервер
авторизации отправит пользовательский агент обратно после
предоставления доступа (или отказа в нём).
(B) Сервер авторизации аутентифицирует владельца ресурса
(посредством пользовательского агента) и устанавливает,
удовлетворяет ли владелец ресурса запрос клиента на доступ
или отклоняет его.
(C) При условии, что владелец ресурса предоставляет доступ, сервер
авторизации перенаправляет пользовательский агент обратно к
клиенту с использованием ранее предоставленного URI
перенаправления. URI перенаправления содержит токен доступа
во фрагменте URI.
(D) Пользовательский агент следует указаниям перенаправления,
выполняя запрос к размещённому в вебе ресурсу клиента
(этот запрос не включает фрагмент согласно [RFC2616]).
Пользовательский агент сохраняет информацию фрагмента локально.
(E) Размещённый в вебе ресурс клиента возвращает веб-страницу
(обычно HTML-документ со встроенным сценарием), способную
получить доступ к полному URI перенаправления, включая
фрагмент, сохранённый пользовательским агентом, и извлечь
токен доступа (и другие параметры), содержащиеся во фрагменте.
(F) Пользовательский агент локально выполняет сценарий,
предоставленный размещённым в вебе ресурсом клиента;
этот сценарий извлекает токен доступа.
(G) Пользовательский агент передаёт токен доступа клиенту.
Общие сведения об использовании неявного предоставления полномочий
см. в разделах 1.3.2 и 9. Важные соображения безопасности при
использовании неявного предоставления полномочий см. в разделах
10.3 и 10.16.
4.2.1. Запрос авторизации
Клиент формирует URI запроса, добавляя следующие параметры в компонент
запроса URI конечной точки авторизации с использованием формата
"application/x-www-form-urlencoded" согласно приложению B:
response_type
ДОЛЖЕН присутствовать (REQUIRED). Значение ДОЛЖНО (MUST)
быть установлено в "token".
client_id
ДОЛЖЕН присутствовать (REQUIRED). Идентификатор клиента,
описанный в разделе 2.2.
redirect_uri
НЕОБЯЗАТЕЛЬНО (OPTIONAL). Как описано в разделе 3.1.2.
scope
НЕОБЯЗАТЕЛЬНО (OPTIONAL). Область запрашиваемого доступа,
описанная в разделе 3.3.
state
СЛЕДУЕТ использовать (RECOMMENDED). Непрозрачное значение,
используемое клиентом для сохранения состояния между запросом
и обратным вызовом. Сервер авторизации включает это значение
при перенаправлении пользовательского агента обратно к клиенту.
Параметр СЛЕДУЕТ (SHOULD) использовать для предотвращения
подделки межсайтовых запросов, как описано в разделе 10.12.
Клиент направляет владельца ресурса на сформированный 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
Сервер авторизации проверяет запрос, чтобы удостовериться, что все
обязательные параметры присутствуют и действительны. Сервер
авторизации ДОЛЖЕН (MUST) проверить, что URI перенаправления, на
который он перенаправит токен доступа, соответствует URI
перенаправления, зарегистрированному клиентом, как описано
в разделе 3.1.2.
Если запрос действителен, сервер авторизации аутентифицирует владельца
ресурса и получает решение об авторизации (запрашивая его у владельца
ресурса или устанавливая одобрение иными средствами).
Когда решение принято, сервер авторизации направляет пользовательский
агент на предоставленный URI перенаправления клиента с помощью
HTTP-ответа перенаправления или иными доступными ему средствами
через пользовательский агент.
4.2.2. Ответ с токеном доступа
Если владелец ресурса удовлетворяет запрос на доступ, сервер
авторизации выдаёт токен доступа и доставляет его клиенту, добавляя
следующие параметры в компонент фрагмента URI перенаправления с
использованием формата "application/x-www-form-urlencoded" согласно
приложению B:
access_token
ДОЛЖЕН присутствовать (REQUIRED). Токен доступа, выданный
сервером авторизации.
token_type
ДОЛЖЕН присутствовать (REQUIRED). Тип выданного токена,
описанный в разделе 7.1. Значение нечувствительно к регистру.
expires_in
СЛЕДУЕТ использовать (RECOMMENDED). Срок действия токена
доступа в секундах. Например, значение "3600" означает, что
срок действия токена доступа истечёт через один час с момента
формирования ответа. Если параметр опущен, серверу авторизации
СЛЕДУЕТ (SHOULD) предоставить время истечения срока действия
иными средствами или документировать значение по умолчанию.
scope
НЕОБЯЗАТЕЛЬНО (OPTIONAL), если область доступа совпадает с
запрошенной клиентом; в противном случае ДОЛЖЕН присутствовать
(REQUIRED). Область доступа токена, описанная в разделе 3.3.
state
ДОЛЖЕН присутствовать (REQUIRED), если параметр "state"
присутствовал в запросе авторизации клиента. Точное значение,
полученное от клиента.
Сервер авторизации НЕ ДОЛЖЕН (MUST NOT) выдавать токен обновления.
Например, сервер авторизации перенаправляет пользовательский агент,
отправляя следующий HTTP-ответ (дополнительные переносы строк
добавлены только для отображения):
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
Разработчикам следует учитывать, что некоторые пользовательские
агенты не поддерживают включение компонента фрагмента в поле
заголовка HTTP-ответа "Location". Для таких клиентов потребуется
использовать другие способы перенаправления клиента вместо ответа
перенаправления 3xx — например, возвращать HTML-страницу, содержащую
кнопку «продолжить» с действием, связанным с URI перенаправления.
Клиент ДОЛЖЕН (MUST) игнорировать нераспознанные параметры ответа.
Размер строки токена доступа в этой спецификации не определён.
Клиенту следует избегать предположений о размерах значений. Серверу
авторизации СЛЕДУЕТ (SHOULD) документировать размер каждого
выдаваемого им значения.
4.2.2.1. Ответ об ошибке
Если запрос завершается неудачно из-за отсутствующего, недействительного
или несовпадающего URI перенаправления либо если идентификатор клиента
отсутствует или недействителен, серверу авторизации СЛЕДУЕТ (SHOULD)
сообщить владельцу ресурса об ошибке, и сервер авторизации НЕ ДОЛЖЕН
(MUST NOT) автоматически перенаправлять пользовательский агент на
недействительный URI перенаправления.
Если владелец ресурса отклоняет запрос на доступ или запрос завершается
неудачно по причинам, отличным от отсутствующего или недействительного
URI перенаправления, сервер авторизации сообщает об этом клиенту,
добавляя следующие параметры в компонент фрагмента URI перенаправления
с использованием формата "application/x-www-form-urlencoded" согласно
приложению B:
error
ДОЛЖЕН присутствовать (REQUIRED). Один код ошибки 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" НЕ ДОЛЖНЫ (MUST NOT) содержать символы
вне набора %x20-21 / %x23-5B / %x5D-7E.
error_description
НЕОБЯЗАТЕЛЬНО (OPTIONAL). Понятный человеку текст в кодировке
ASCII [USASCII], предоставляющий дополнительную информацию,
которая помогает разработчику клиента понять возникшую ошибку.
Значения параметра "error_description" НЕ ДОЛЖНЫ (MUST NOT)
содержать символы вне набора %x20-21 / %x23-5B / %x5D-7E.
error_uri
НЕОБЯЗАТЕЛЬНО (OPTIONAL). URI, идентифицирующий понятную человеку
веб-страницу с информацией об ошибке и используемый для
предоставления разработчику клиента дополнительной информации
об ошибке.
Значения параметра "error_uri" ДОЛЖНЫ (MUST) соответствовать
синтаксису URI-reference и поэтому НЕ ДОЛЖНЫ (MUST NOT)
содержать символы вне набора %x21 / %x23-5B / %x5D-7E.
state
ДОЛЖЕН (REQUIRED) присутствовать, если параметр "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
| Учётные данные с паролем
(A) владельца ресурса
|
v
+---------+ +---------------+
| |>--(B)---- Учётные данные с паролем ------------>| |
| | владельца ресурса | Сервер |
| Клиент | | авторизации |
| |<--(C)------------ Токен доступа ---------------<| |
| | (с необязательным токеном обновления) | |
+---------+ +---------------+
Рисунок 5: Поток с использованием пароля владельца ресурса
Поток, показанный на рисунке 5, включает следующие шаги:
(A) Владелец ресурса предоставляет клиенту своё имя пользователя
и пароль.
(B) Клиент запрашивает токен доступа в конечной точке токенов сервера
авторизации, включая в запрос учётные данные, полученные от
владельца ресурса. При выполнении запроса клиент проходит
аутентификацию на сервере авторизации.
(C) Сервер авторизации аутентифицирует клиента и проверяет учётные
данные владельца ресурса и, если они действительны, выдаёт
токен доступа.
4.3.1. Запрос и ответ авторизации
Способ, которым клиент получает учётные данные владельца ресурса,
выходит за рамки этой спецификации. Клиент ДОЛЖЕН (MUST) удалить
учётные данные сразу после получения токена доступа.
4.3.2. Запрос токена доступа
Клиент выполняет запрос к конечной точке токенов, добавляя следующие
параметры в тело сущности запроса HTTP в формате
"application/x-www-form-urlencoded" согласно приложению B с
кодировкой символов UTF-8:
grant_type
ДОЛЖЕН (REQUIRED) присутствовать. Значение ДОЛЖНО (MUST) быть
установлено в "password".
username
ДОЛЖЕН (REQUIRED) присутствовать. Имя пользователя владельца
ресурса.
password
ДОЛЖЕН (REQUIRED) присутствовать. Пароль владельца ресурса.
scope
НЕОБЯЗАТЕЛЬНО (OPTIONAL). Область действия запроса доступа,
описанная в разделе 3.3.
Если тип клиента — конфиденциальный или клиенту были выданы учётные
данные клиента (либо назначены другие требования к аутентификации),
клиент ДОЛЖЕН (MUST) пройти аутентификацию на сервере авторизации,
как описано в разделе 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
Сервер авторизации ДОЛЖЕН (MUST):
o требовать аутентификацию клиента для конфиденциальных клиентов
или для любого клиента, которому были выданы учётные данные
клиента (либо для которого установлены другие требования
к аутентификации),
o аутентифицировать клиента, если в запрос включены данные для
аутентификации клиента, и
o проверять учётные данные с паролем владельца ресурса с помощью
своего существующего алгоритма проверки паролей.
Поскольку в этом запросе токена доступа используется пароль владельца
ресурса, сервер авторизации ДОЛЖЕН (MUST) защищать конечную точку от
атак методом перебора (например, ограничивая частоту запросов или
формируя оповещения).
4.3.3. Ответ с токеном доступа
Если запрос токена доступа корректен и авторизован, сервер авторизации
выдаёт токен доступа и необязательный токен обновления, как описано
в разделе 5.1. Если аутентификация клиента при выполнении запроса
не удалась или запрос некорректен, сервер авторизации возвращает
ответ с ошибкой, как описано в разделе 5.2.
Пример успешного ответа:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
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. Предоставление полномочий с использованием учётных данных клиента
Клиент может запросить токен доступа, используя только свои учётные
данные клиента (или другие поддерживаемые средства аутентификации),
когда он запрашивает доступ к защищённым ресурсам, находящимся под
его управлением, либо к ресурсам другого владельца, доступ к которым
был предварительно согласован с сервером авторизации (способ такого
согласования выходит за рамки этой спецификации).
Тип предоставления полномочий с использованием учётных данных клиента
ДОЛЖЕН (MUST) использоваться только конфиденциальными клиентами.
+---------+ +---------------+
| | | |
| |>--(A)------ Аутентификация клиента ------------>| Сервер |
| Клиент | | авторизации |
| |<--(B)------------ Токен доступа ---------------<| |
| | | |
+---------+ +---------------+
Рисунок 6: Поток с использованием учётных данных клиента
Поток, показанный на рисунке 6, включает следующие шаги:
(A) Клиент проходит аутентификацию на сервере авторизации и
запрашивает токен доступа в конечной точке токенов.
(B) Сервер авторизации аутентифицирует клиента и в случае успешной
аутентификации выдаёт токен доступа.
4.4.1. Запрос и ответ авторизации
Поскольку аутентификация клиента используется в качестве предоставления
полномочий, дополнительный запрос авторизации не требуется.
4.4.2. Запрос токена доступа
Клиент выполняет запрос к конечной точке токенов, добавляя следующие
параметры в тело сущности запроса HTTP в формате
"application/x-www-form-urlencoded" согласно приложению B с
кодировкой символов UTF-8:
grant_type
ДОЛЖЕН (REQUIRED) присутствовать. Значение ДОЛЖНО (MUST) быть
установлено в "client_credentials".
scope
НЕОБЯЗАТЕЛЬНО (OPTIONAL). Область действия запроса доступа,
описанная в разделе 3.3.
Клиент ДОЛЖЕН (MUST) пройти аутентификацию на сервере авторизации,
как описано в разделе 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
Сервер авторизации ДОЛЖЕН (MUST) аутентифицировать клиента.
4.4.3. Ответ с токеном доступа
Если запрос токена доступа корректен и авторизован, сервер авторизации
выдаёт токен доступа, как описано в разделе 5.1. Токен обновления
НЕ СЛЕДУЕТ (SHOULD NOT) включать в ответ. Если аутентификация клиента
при выполнении запроса не удалась или запрос некорректен, сервер
авторизации возвращает ответ с ошибкой, как описано в разделе 5.2.
Пример успешного ответа:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
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" конечной точки токенов
и добавляя все необходимые дополнительные параметры.
Например, чтобы запросить токен доступа с использованием типа
предоставления полномочий на основе утверждения Security Assertion
Markup Language (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
[...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
Если запрос токена доступа корректен и авторизован, сервер авторизации
выдаёт токен доступа и необязательный токен обновления, как описано
в разделе 5.1. Если аутентификация клиента при выполнении запроса
не удалась или запрос некорректен, сервер авторизации возвращает
ответ с ошибкой, как описано в разделе 5.2.
5. Выдача токена доступа
Если запрос токена доступа корректен и авторизован, сервер авторизации
выдаёт токен доступа и необязательный токен обновления, как описано
в разделе 5.1. Если аутентификация клиента при выполнении запроса
не удалась или запрос некорректен, сервер авторизации возвращает
ответ с ошибкой, как описано в разделе 5.2.
5.1. Успешный ответ
Сервер авторизации выдаёт токен доступа и необязательный токен
обновления и формирует ответ, добавляя следующие параметры в тело
сущности ответа HTTP с кодом состояния 200 (OK):
access_token
ДОЛЖЕН (REQUIRED) присутствовать. Токен доступа, выданный
сервером авторизации.
token_type
ДОЛЖЕН (REQUIRED) присутствовать. Тип выданного токена, как
описано в разделе 7.1. Значение нечувствительно к регистру.
expires_in
СЛЕДУЕТ (RECOMMENDED) включать. Время жизни токена доступа
в секундах. Например, значение "3600" означает, что срок
действия токена доступа истечёт через один час с момента
формирования ответа. Если параметр опущен, серверу авторизации
СЛЕДУЕТ (SHOULD) предоставить время истечения срока действия
другими средствами или документировать значение по умолчанию.
refresh_token
НЕОБЯЗАТЕЛЬНО (OPTIONAL). Токен обновления, который можно
использовать для получения новых токенов доступа на основе
того же предоставления полномочий, как описано в разделе 6.
scope
НЕОБЯЗАТЕЛЬНО (OPTIONAL), если область действия совпадает с
запрошенной клиентом; в противном случае ДОЛЖЕН (REQUIRED)
присутствовать. Область действия токена доступа, описанная
в разделе 3.3.
Параметры включаются в тело сущности HTTP-ответа с использованием типа
данных "application/json", определённого в [RFC4627]. Параметры
сериализуются в структуру JavaScript Object Notation (JSON) путём
добавления каждого параметра на верхнем уровне структуры.
Имена параметров и строковые значения включаются как строки JSON.
Числовые значения включаются как числа JSON. Порядок параметров
не имеет значения и может различаться.
Сервер авторизации ДОЛЖЕН (MUST) включать в любой ответ, содержащий
токены, учётные данные или другую конфиденциальную информацию,
поле заголовка HTTP-ответа "Cache-Control" [RFC2616] со значением
"no-store", а также поле заголовка ответа "Pragma" [RFC2616]
со значением "no-cache".
Например:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
Клиент ДОЛЖЕН (MUST) игнорировать нераспознанные имена значений
в ответе. Размеры токенов и других значений, получаемых от сервера
авторизации, не определены. Клиенту следует избегать предположений
о размерах значений. Серверу авторизации СЛЕДУЕТ (SHOULD)
документировать размер каждого выдаваемого им значения.
5.2. Ответ об ошибке
Сервер авторизации отвечает кодом состояния HTTP 400 (Bad Request)
(если не указано иное) и включает в ответ следующие параметры:
error
ДОЛЖЕН присутствовать (REQUIRED). Один из следующих кодов
ошибки в ASCII [USASCII]:
invalid_request
В запросе отсутствует обязательный параметр, указано
неподдерживаемое значение параметра (кроме типа
предоставления авторизации), повторяется параметр,
включено несколько наборов учётных данных, используется
более одного механизма аутентификации клиента либо
запрос некорректно сформирован по иной причине.
invalid_client
Аутентификация клиента завершилась неудачей (например,
клиент неизвестен, данные для аутентификации клиента
не включены либо метод аутентификации не поддерживается).
Сервер авторизации МОЖЕТ (MAY) вернуть код состояния
HTTP 401 (Unauthorized), чтобы указать, какие схемы
HTTP-аутентификации поддерживаются. Если клиент попытался
пройти аутентификацию с помощью поля заголовка запроса
"Authorization", сервер авторизации ДОЛЖЕН (MUST)
ответить кодом состояния HTTP 401 (Unauthorized)
и включить поле заголовка ответа "WWW-Authenticate",
соответствующее схеме аутентификации, использованной
клиентом.
invalid_grant
Предоставленное разрешение на авторизацию (например,
код авторизации или учётные данные владельца ресурса)
либо токен обновления недействителен, просрочен, отозван,
не соответствует URI перенаправления, использованному
в запросе авторизации, либо был выдан другому клиенту.
unauthorized_client
Аутентифицированному клиенту не разрешено использовать
этот тип предоставления авторизации.
unsupported_grant_type
Этот тип предоставления авторизации не поддерживается
сервером авторизации.
invalid_scope
Запрошенная область доступа недействительна, неизвестна,
некорректно сформирована либо превышает область доступа,
предоставленную владельцем ресурса.
Значения параметра "error" НЕ ДОЛЖНЫ (MUST NOT) включать
символы вне набора %x20-21 / %x23-5B / %x5D-7E.
error_description
НЕОБЯЗАТЕЛЬНО (OPTIONAL). Понятный человеку текст в ASCII
[USASCII], содержащий дополнительную информацию и помогающий
разработчику клиента понять возникшую ошибку.
Значения параметра "error_description" НЕ ДОЛЖНЫ (MUST NOT)
включать символы вне набора %x20-21 / %x23-5B / %x5D-7E.
error_uri
НЕОБЯЗАТЕЛЬНО (OPTIONAL). URI, идентифицирующий понятную
человеку веб-страницу с информацией об ошибке и используемый
для предоставления разработчику клиента дополнительной
информации об ошибке.
Значения параметра "error_uri" ДОЛЖНЫ (MUST) соответствовать
синтаксису URI-reference и, следовательно, НЕ ДОЛЖНЫ (MUST NOT)
включать символы вне набора %x21 / %x23-5B / %x5D-7E.
Параметры включаются в тело сущности HTTP-ответа с использованием
типа данных "application/json", определённого в [RFC4627].
Параметры сериализуются в структуру JSON путём добавления каждого
параметра на верхнем уровне структуры. Имена параметров и строковые
значения включаются как строки JSON. Числовые значения включаются
как числа JSON. Порядок параметров не имеет значения и может
различаться.
Например:
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"error":"invalid_request"
}
6. Обновление токена доступа
Если сервер авторизации выдал клиенту токен обновления, клиент
отправляет запрос на обновление в конечную точку токенов, добавляя
следующие параметры в тело сущности HTTP-запроса в формате
"application/x-www-form-urlencoded" согласно Приложению B
с кодировкой символов UTF-8:
grant_type
ДОЛЖЕН присутствовать (REQUIRED). Значение ДОЛЖНО (MUST)
быть установлено в "refresh_token".
refresh_token
ДОЛЖЕН присутствовать (REQUIRED). Токен обновления,
выданный клиенту.
scope
НЕОБЯЗАТЕЛЬНО (OPTIONAL). Область запрашиваемого доступа,
описанная в Разделе 3.3. Запрошенная область доступа
НЕ ДОЛЖНА (MUST NOT) включать какие-либо права доступа,
первоначально не предоставленные владельцем ресурса;
если параметр опущен, область доступа считается равной
первоначально предоставленной владельцем ресурса.
Поскольку токены обновления обычно являются долгоживущими учётными
данными, используемыми для запроса дополнительных токенов доступа,
токен обновления привязывается к клиенту, которому он был выдан.
Если клиент относится к конфиденциальному типу или ему были выданы
учётные данные клиента (либо для него установлены другие требования
к аутентификации), клиент ДОЛЖЕН (MUST) пройти аутентификацию
на сервере авторизации, как описано в Разделе 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
Сервер авторизации ДОЛЖЕН (MUST):
o требовать аутентификацию клиента для конфиденциальных клиентов
или любого клиента, которому были выданы учётные данные клиента
(либо для которого установлены другие требования к аутентификации),
o аутентифицировать клиента, если в запрос включены данные для
аутентификации клиента, и убедиться, что токен обновления был
выдан аутентифицированному клиенту, а также
o проверить действительность токена обновления.
Если запрос действителен и разрешён, сервер авторизации выдаёт токен
доступа, как описано в Разделе 5.1. Если запрос не прошёл проверку
или недействителен, сервер авторизации возвращает ответ об ошибке,
как описано в Разделе 5.2.
Сервер авторизации МОЖЕТ (MAY) выдать новый токен обновления;
в этом случае клиент ДОЛЖЕН (MUST) отбросить старый токен обновления
и заменить его новым. Сервер авторизации МОЖЕТ (MAY) отозвать старый
токен обновления после выдачи клиенту нового токена обновления.
Если выдаётся новый токен обновления, его область доступа ДОЛЖНА
(MUST) быть идентична области доступа токена обновления, включённого
клиентом в запрос.
7. Доступ к защищённым ресурсам
Клиент получает доступ к защищённым ресурсам, предъявляя токен доступа
серверу ресурсов. Сервер ресурсов ДОЛЖЕН (MUST) проверить
действительность токена доступа и убедиться, что срок его действия
не истёк и что его область доступа охватывает запрошенный ресурс.
Методы, используемые сервером ресурсов для проверки действительности
токена доступа (а также любые ответы об ошибках), выходят за рамки
настоящей спецификации, но обычно предполагают взаимодействие или
координацию между сервером ресурсов и сервером авторизации.
Способ, которым клиент использует токен доступа для аутентификации
на сервере ресурсов, зависит от типа токена доступа, выданного
сервером авторизации. Обычно для этого используется поле заголовка
HTTP-запроса "Authorization" [RFC2617] со схемой аутентификации,
определённой спецификацией используемого типа токена доступа,
например [RFC6750].
7.1. Типы токенов доступа
Тип токена доступа предоставляет клиенту информацию, необходимую
для успешного использования токена доступа при запросе защищённого
ресурса (наряду с атрибутами, специфичными для данного типа).
Клиент НЕ ДОЛЖЕН (MUST NOT) использовать токен доступа, если
он не понимает тип токена.
Например, тип токена "bearer", определённый в [RFC6750], используется
путём простого включения строки токена доступа в запрос:
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
тогда как тип токена "mac", определённый в [OAuth-HTTP-MAC],
используется путём выдачи вместе с токеном доступа ключа кода
аутентификации сообщения (Message Authentication Code, 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. Ответ об ошибке
Если запрос доступа к ресурсу завершился неудачей, серверу ресурсов
СЛЕДУЕТ (SHOULD) сообщить клиенту об ошибке. Хотя подробности таких
ответов об ошибках выходят за рамки настоящей спецификации, этот
документ учреждает в Разделе 11.4 общий реестр значений ошибок
для совместного использования схемами аутентификации с токенами OAuth.
Новым схемам аутентификации, предназначенным преимущественно для
аутентификации с токенами OAuth, СЛЕДУЕТ (SHOULD) определять механизм
предоставления клиенту кода состояния ошибки, допустимые значения
ошибок которого зарегистрированы в реестре ошибок, учреждённом
настоящей спецификацией.
Такие схемы МОГУТ (MAY) ограничивать набор допустимых кодов ошибок
подмножеством зарегистрированных значений. Если код ошибки
возвращается с помощью именованного параметра, имя этого параметра
СЛЕДУЕТ (SHOULD) задавать как "error".
Другие схемы, которые могут использоваться для аутентификации
с токенами OAuth, но не предназначены преимущественно для этой цели,
МОГУТ (MAY) связывать свои значения ошибок с реестром таким же образом.
Новые схемы аутентификации МОГУТ (MAY) также определять использование
параметров "error_description" и "error_uri" для возврата информации
об ошибках способом, аналогичным их использованию в настоящей
спецификации.
8.1. Определение типов токенов доступа
Типы токенов доступа могут определяться одним из двух способов:
регистрацией в реестре Access Token Types (в соответствии
с процедурами Раздела 11.1) либо использованием уникального
абсолютного URI в качестве имени типа.
Типы, использующие URI в качестве имени, СЛЕДУЕТ (SHOULD) ограничивать
реализациями конкретных поставщиков, которые не имеют широкого
применения и обусловлены особенностями реализации сервера ресурсов,
на котором они используются.
Все остальные типы ДОЛЖНЫ (MUST) быть зарегистрированы. Имена типов
ДОЛЖНЫ (MUST) соответствовать ABNF для type-name. Если определение
типа включает новую схему HTTP-аутентификации, имя типа СЛЕДУЕТ
(SHOULD) делать идентичным имени схемы HTTP-аутентификации
(определённому в [RFC2617]). Тип токена "example" зарезервирован
для использования в примерах.
type-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
8.2. Определение новых параметров конечных точек
Новые параметры запросов или ответов для использования с конечной
точкой авторизации или конечной точкой токенов определяются
и регистрируются в реестре OAuth Parameters в соответствии
с процедурой Раздела 11.2.
Имена параметров ДОЛЖНЫ (MUST) соответствовать ABNF для param-name,
а синтаксис значений параметров ДОЛЖЕН (MUST) быть чётко определён
(например, с помощью ABNF или ссылки на синтаксис существующего
параметра).
param-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
Незарегистрированным расширениям параметров, специфичным для поставщика, которые не имеют общего применения и относятся к деталям реализации сервера авторизации, на котором они используются, СЛЕДУЕТ (SHOULD) использовать специфичный для поставщика префикс, который с малой вероятностью будет конфликтовать с другими зарегистрированными значениями (например, начинаться с 'companyname_').
8.3. Определение новых типов предоставления авторизации
Новые типы предоставления авторизации можно определять, назначая им уникальный абсолютный URI для использования с параметром "grant_type". Если тип предоставления авторизации, определённый расширением, требует дополнительных параметров конечной точки токенов, они ДОЛЖНЫ (MUST) быть зарегистрированы в реестре OAuth Parameters, как описано в разделе 11.2.
8.4. Определение новых типов ответа конечной точки авторизации
Новые типы ответа для использования с конечной точкой авторизации определяются и регистрируются в реестре Authorization Endpoint Response Types в соответствии с процедурой из раздела 11.3. Имена типов ответа ДОЛЖНЫ (MUST) соответствовать ABNF для response-type.
response-type = response-name *( SP response-name )
response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA
Если тип ответа содержит один или несколько символов пробела (%x20), при сравнении он рассматривается как список значений, разделённых пробелами, в котором порядок значений не имеет значения. Зарегистрировать можно только один порядок значений, который охватывает все остальные перестановки того же набора значений.
Например, тип ответа "token code" в данной спецификации оставлен неопределённым. Однако расширение может определить и зарегистрировать тип ответа "token code". После регистрации та же комбинация не может быть зарегистрирована как "code token", но оба значения могут использоваться для обозначения одного и того же типа ответа.
8.5. Определение дополнительных кодов ошибок
В случаях, когда расширения протокола (то есть типы токенов доступа, параметры расширений или типы предоставления авторизации, определённые расширениями) требуют дополнительных кодов ошибок для использования в ответе об ошибке при предоставлении авторизации с использованием кода авторизации (раздел 4.1.2.1), ответе об ошибке при неявном предоставлении авторизации (раздел 4.2.2.1), ответе об ошибке при запросе токена (раздел 5.2) или ответе об ошибке доступа к ресурсу (раздел 7.2), такие коды ошибок МОГУТ (MAY) быть определены.
Коды ошибок расширений ДОЛЖНЫ (MUST) быть зарегистрированы (в соответствии с процедурами из раздела 11.4), если расширение, совместно с которым они используются, является зарегистрированным типом токена доступа, зарегистрированным параметром конечной точки или типом предоставления авторизации, определённым расширением. Коды ошибок, используемые с незарегистрированными расширениями, МОГУТ (MAY) быть зарегистрированы.
Коды ошибок ДОЛЖНЫ (MUST) соответствовать ABNF для error, и, по возможности, к ним СЛЕДУЕТ (SHOULD) добавлять в качестве префикса идентифицирующее имя. Например, ошибку, указывающую на недопустимое значение, заданное параметру расширения "example", СЛЕДУЕТ (SHOULD) назвать "example_invalid".
error = 1*error-char
error-char = %x20-21 / %x23-5B / %x5D-7E
9. Нативные приложения
Нативные приложения — это клиенты, установленные и выполняемые на устройстве, которым пользуется владелец ресурса (то есть настольное приложение, нативное мобильное приложение). Нативные приложения требуют особого рассмотрения с точки зрения безопасности, возможностей платформы и общего удобства работы конечного пользователя.
Конечная точка авторизации требует взаимодействия между клиентом и пользовательским агентом владельца ресурса. Нативные приложения могут вызывать внешний пользовательский агент или встраивать пользовательский агент в приложение. Например:
o Внешний пользовательский агент — нативное приложение может получить ответ от сервера авторизации, используя URI перенаправления со схемой, зарегистрированной в операционной системе для вызова клиента в качестве обработчика, ручное копирование и вставку учётных данных, запуск локального веб-сервера, установку расширения пользовательского агента либо предоставление URI перенаправления, идентифицирующего размещённый на сервере ресурс под управлением клиента, который, в свою очередь, делает ответ доступным нативному приложению.
o Встроенный пользовательский агент — нативное приложение получает ответ посредством прямого взаимодействия со встроенным пользовательским агентом, отслеживая изменения состояния, о которых тот сообщает во время загрузки ресурса, или обращаясь к хранилищу файлов cookie пользовательского агента.
При выборе между внешним и встроенным пользовательским агентом разработчикам следует учитывать следующее:
o Внешний пользовательский агент может повысить долю успешно завершённых процессов, поскольку у владельца ресурса уже может быть активный сеанс с сервером авторизации, что устраняет необходимость повторной аутентификации. Он обеспечивает привычные конечному пользователю взаимодействие и функциональность. Владелец
ресурса также может полагаться на функции или расширения пользовательского агента, помогающие при аутентификации (например, менеджер паролей, считыватель устройства двухфакторной аутентификации).
o Встроенный пользовательский агент может обеспечить большее удобство использования, поскольку устраняет необходимость переключать контекст и открывать новые окна.
o Встроенный пользовательский агент создаёт проблему безопасности, поскольку владельцы ресурсов проходят аутентификацию в неидентифицированном окне без доступа к визуальным средствам защиты, имеющимся в большинстве внешних пользовательских агентов. Встроенный пользовательский агент приучает конечных пользователей доверять неидентифицированным запросам на аутентификацию (облегчая проведение фишинговых атак).
При выборе между неявным типом предоставления авторизации и типом предоставления авторизации с использованием кода авторизации следует учитывать следующее:
o Нативным приложениям, использующим тип предоставления авторизации с использованием кода авторизации, СЛЕДУЕТ (SHOULD) делать это без использования учётных данных клиента, поскольку нативное приложение не способно сохранять конфиденциальность учётных данных клиента.
o При использовании потока неявного предоставления авторизации токен обновления не возвращается, что требует повторения процесса авторизации по истечении срока действия токена доступа.
10. Соображения безопасности
Поскольку OAuth представляет собой гибкий и расширяемый каркас, соображения его безопасности зависят от многих факторов. Следующие разделы предоставляют разработчикам реализаций рекомендации по безопасности, ориентированные на три профиля клиентов, описанные в разделе 2.1: веб-приложение, приложение на основе пользовательского агента и нативное приложение.
Всесторонняя модель безопасности OAuth и её анализ, а также предпосылки проектирования протокола приведены в [OAuth-THREATMODEL].
10.1. Аутентификация клиента
Сервер авторизации устанавливает учётные данные для клиентов в виде веб-приложений с целью аутентификации клиентов. Серверу авторизации предлагается рассмотреть более надёжные средства аутентификации клиента, чем пароль клиента. Клиенты в виде веб-приложений ДОЛЖНЫ (MUST) обеспечивать конфиденциальность паролей клиентов и других учётных данных клиентов.
Сервер авторизации НЕ ДОЛЖЕН (MUST NOT) выдавать пароли клиентов или другие учётные данные клиентов клиентам в виде нативных приложений или приложений на основе пользовательского агента с целью аутентификации клиентов. Сервер авторизации МОЖЕТ (MAY) выдать пароль клиента или другие учётные данные для конкретной установки клиента в виде нативного приложения на конкретном устройстве.
Когда аутентификация клиента невозможна, серверу авторизации СЛЕДУЕТ (SHOULD) использовать другие средства для проверки идентичности клиента — например, требовать регистрации URI перенаправления клиента или привлекать владельца ресурса для подтверждения идентичности. Допустимого URI перенаправления недостаточно для проверки идентичности клиента при запросе авторизации у владельца ресурса, но его можно использовать для предотвращения передачи учётных данных поддельному клиенту после получения авторизации от владельца ресурса.
Сервер авторизации должен учитывать последствия взаимодействия с неаутентифицированными клиентами для безопасности и принимать меры для ограничения потенциального раскрытия других учётных данных (например, токенов обновления), выданных таким клиентам.
10.2. Выдача себя за другого клиента
Злонамеренный клиент может выдать себя за другого клиента и получить доступ к защищённым ресурсам, если клиент, за которого он себя выдаёт, не обеспечивает или не способен обеспечить конфиденциальность своих учётных данных клиента.
Сервер авторизации ДОЛЖЕН (MUST) аутентифицировать клиента всякий раз, когда это возможно. Если сервер авторизации не может аутентифицировать клиента из-за особенностей клиента, сервер авторизации ДОЛЖЕН (MUST) требовать регистрации любого URI перенаправления, используемого для получения ответов авторизации, и ему СЛЕДУЕТ (SHOULD) использовать другие средства защиты владельцев ресурсов от таких потенциально злонамеренных клиентов. Например, сервер авторизации может привлечь владельца ресурса для помощи в идентификации клиента и его происхождения.
Серверу авторизации СЛЕДУЕТ (SHOULD) требовать явной аутентификации владельца ресурса и предоставлять владельцу ресурса сведения о клиенте, а также о запрашиваемых области действия и сроке действия авторизации. Владелец ресурса сам решает, как оценить эти сведения применительно к текущему клиенту и разрешить или отклонить запрос.
Серверу авторизации НЕ СЛЕДУЕТ (SHOULD NOT) автоматически обрабатывать повторные запросы авторизации (без активного взаимодействия с владельцем ресурса), не аутентифицируя клиента и не опираясь на другие меры, позволяющие убедиться, что повторный запрос поступает от исходного клиента, а не от того, кто выдаёт себя за него.
10.3. Токены доступа
Конфиденциальность учётных данных токенов доступа (а также любых конфиденциальных атрибутов токенов доступа) ДОЛЖНА (MUST) сохраняться при передаче и хранении, и они должны быть доступны только серверу авторизации, серверам ресурсов, для которых действителен токен доступа, и клиенту, которому выдан токен доступа. Учётные данные токенов доступа ДОЛЖНЫ (MUST) передаваться только с использованием TLS, как описано в разделе 1.6, с аутентификацией сервера, определённой в [RFC2818].
При использовании неявного типа предоставления авторизации токен доступа передаётся во фрагменте URI, что может привести к его раскрытию неуполномоченным сторонам.
Сервер авторизации ДОЛЖЕН (MUST) обеспечивать невозможность получения неуполномоченными сторонами действительных токенов доступа путём генерации, изменения или угадывания токенов доступа.
Клиенту СЛЕДУЕТ (SHOULD) запрашивать токены доступа с минимально необходимой областью действия. Серверу авторизации СЛЕДУЕТ (SHOULD) учитывать идентичность клиента при принятии решения о том, как удовлетворить запрос на область действия, и он МОЖЕТ (MAY) выдать токен доступа с меньшими правами, чем запрошено.
Данная спецификация не предоставляет серверу ресурсов каких-либо методов, позволяющих убедиться, что токен доступа, предъявленный ему данным клиентом, был выдан сервером авторизации именно этому клиенту.
10.4. Токены обновления
Серверы авторизации МОГУТ (MAY) выдавать токены обновления клиентам в виде веб-приложений и нативных приложений.
Конфиденциальность токенов обновления ДОЛЖНА (MUST) сохраняться при передаче и хранении, и они должны быть доступны только серверу авторизации и клиенту, которому были выданы токены обновления. Сервер авторизации ДОЛЖЕН (MUST) сохранять привязку токена обновления к клиенту, которому он был выдан. Токены обновления ДОЛЖНЫ (MUST) передаваться только с использованием TLS, как описано в разделе 1.6, с аутентификацией сервера, определённой в [RFC2818].
Сервер авторизации ДОЛЖЕН (MUST) проверять привязку токена обновления к идентичности клиента всякий раз, когда идентичность клиента может быть аутентифицирована. Когда аутентификация клиента невозможна, серверу авторизации СЛЕДУЕТ (SHOULD) применять другие средства обнаружения злоупотребления токенами обновления.
Например, сервер авторизации мог бы применять ротацию токенов обновления, при которой новый токен обновления выдаётся с каждым ответом на обновление токена доступа. Предыдущий токен обновления аннулируется,
но сохраняется сервером авторизации. Если токен обновления скомпрометирован и впоследствии используется как злоумышленником, так и законным клиентом, один из них предъявит аннулированный токен обновления, что сообщит серверу авторизации о нарушении безопасности.
Сервер авторизации ДОЛЖЕН (MUST) обеспечивать невозможность получения неуполномоченными сторонами действительных токенов обновления путём генерации, изменения или угадывания токенов обновления.
10.5. Коды авторизации
Передачу кодов авторизации СЛЕДУЕТ (SHOULD) осуществлять по защищённому каналу, а клиенту СЛЕДУЕТ (SHOULD) требовать использования TLS с его URI перенаправления, если этот URI идентифицирует сетевой ресурс. Поскольку коды авторизации передаются посредством перенаправлений пользовательского агента, они потенциально могут быть раскрыты через историю пользовательского агента и HTTP-заголовки источника перехода.
Коды авторизации действуют как учётные данные предъявителя (bearer credentials) в виде открытого текста, используемые для проверки того, что владелец ресурса, предоставивший авторизацию на сервере авторизации, является тем же владельцем ресурса, который возвращается к клиенту для завершения процесса. Поэтому, если клиент полагается на код авторизации для собственной аутентификации владельца ресурса, конечная точка перенаправления клиента ДОЛЖНА (MUST) требовать использования TLS.
Коды авторизации ДОЛЖНЫ (MUST) иметь короткий срок действия и быть одноразовыми. Если сервер авторизации обнаруживает несколько попыток обменять код авторизации на токен доступа, серверу авторизации СЛЕДУЕТ (SHOULD) попытаться отозвать все токены доступа, уже выданные на основании скомпрометированного кода авторизации.
Если клиент может быть аутентифицирован, серверы авторизации ДОЛЖНЫ (MUST) аутентифицировать клиента и убедиться, что код авторизации был выдан тому же клиенту.
10.6. Манипулирование URI перенаправления при использовании кода авторизации
При запросе авторизации с использованием типа предоставления полномочий на основе кода авторизации клиент может указать URI перенаправления с помощью параметра "redirect_uri". Если злоумышленник может изменить значение URI перенаправления, он может заставить сервер авторизации перенаправить пользовательский агент владельца ресурса на подконтрольный злоумышленнику URI вместе с кодом авторизации.
Злоумышленник может создать учётную запись у легитимного клиента и начать процесс авторизации. Когда пользовательский агент злоумышленника направляется на сервер авторизации для предоставления доступа, злоумышленник перехватывает URI авторизации, предоставленный легитимным клиентом, и заменяет
URI перенаправления клиента на подконтрольный злоумышленнику URI. Затем злоумышленник обманом заставляет жертву перейти по изменённой ссылке, чтобы разрешить доступ легитимному клиенту.
На сервере авторизации жертве предъявляется обычный, действительный запрос от имени легитимного и доверенного клиента, и жертва разрешает этот запрос. Затем жертва перенаправляется на подконтрольную злоумышленнику конечную точку вместе с кодом авторизации. Злоумышленник завершает процесс авторизации, отправляя код авторизации клиенту с использованием исходного URI перенаправления, предоставленного клиентом. Клиент обменивает код авторизации на токен доступа и связывает его с учётной записью злоумышленника у клиента, которая теперь позволяет получить доступ к защищённым ресурсам, доступ к которым разрешила жертва (через клиента).
Чтобы предотвратить такую атаку, сервер авторизации ДОЛЖЕН (MUST) обеспечить идентичность URI перенаправления, использованного для получения кода авторизации, и URI перенаправления, предоставленного при обмене кода авторизации на токен доступа. Сервер авторизации ДОЛЖЕН (MUST) требовать от публичных клиентов и ему СЛЕДУЕТ (SHOULD) требовать от конфиденциальных клиентов регистрации их URI перенаправления. Если в запросе предоставлен URI перенаправления, сервер авторизации ДОЛЖЕН (MUST) проверить его на соответствие зарегистрированному значению.
10.7. Парольные учётные данные владельца ресурса
Тип предоставления полномочий на основе парольных учётных данных владельца ресурса часто используется для поддержки устаревших систем или при миграции. Он снижает общий риск, связанный с хранением клиентом имён пользователей и паролей, но не устраняет необходимость раскрывать клиенту учётные данные, предоставляющие широкие полномочия.
Этот тип предоставления полномочий сопряжён с более высоким риском, чем другие типы, поскольку сохраняет антипаттерн использования паролей, которого данный протокол стремится избежать. Клиент может злоупотребить паролем, либо пароль может быть непреднамеренно раскрыт злоумышленнику (например, через файлы журналов или другие записи, которые ведёт клиент).
Кроме того, поскольку владелец ресурса не контролирует процесс авторизации (участие владельца ресурса заканчивается, когда он передаёт свои учётные данные клиенту), клиент может получить токены доступа с более широкой областью действия, чем желает владелец ресурса. Серверу авторизации следует учитывать область действия и срок действия токенов доступа, выдаваемых с использованием этого типа предоставления полномочий.
Серверу авторизации и клиенту СЛЕДУЕТ (SHOULD) свести к минимуму использование этого типа предоставления полномочий и по возможности использовать другие типы.
10.8. Конфиденциальность запросов
Токены доступа, токены обновления, пароли владельцев ресурсов и учётные данные клиентов НЕ ДОЛЖНЫ (MUST NOT) передаваться в незашифрованном виде. Коды авторизации НЕ СЛЕДУЕТ (SHOULD NOT) передавать в незашифрованном виде.
В параметры "state" и "scope" НЕ СЛЕДУЕТ (SHOULD NOT) включать конфиденциальную информацию о клиенте или владельце ресурса в виде открытого текста, поскольку эти параметры могут передаваться по незащищённым каналам или храниться небезопасным образом.
10.9. Обеспечение подлинности конечных точек
Для предотвращения атак посредника сервер авторизации ДОЛЖЕН (MUST) требовать использования TLS с аутентификацией сервера, как определено в [RFC2818], для любого запроса, отправляемого на конечные точки авторизации и выдачи токенов. Клиент ДОЛЖЕН (MUST) проверять TLS-сертификат сервера авторизации, как определено в [RFC6125], и в соответствии с требованиями этого документа к аутентификации идентичности сервера.
10.10. Атаки с угадыванием учётных данных
Сервер авторизации ДОЛЖЕН (MUST) предотвращать угадывание злоумышленниками токенов доступа, кодов авторизации, токенов обновления, паролей владельцев ресурсов и учётных данных клиентов.
Вероятность того, что злоумышленник угадает сгенерированные токены (и другие учётные данные, не предназначенные для непосредственного использования конечными пользователями), ДОЛЖНА (MUST) быть меньше или равна 2^(-128), и ей СЛЕДУЕТ (SHOULD) быть меньше или равной 2^(-160).
Сервер авторизации ДОЛЖЕН (MUST) использовать другие средства защиты учётных данных, предназначенных для использования конечными пользователями.
10.11. Фишинговые атаки
Широкое распространение этого и подобных протоколов может привести к тому, что конечные пользователи привыкнут к перенаправлению на веб-сайты, где их просят ввести пароли. Если конечные пользователи не будут тщательно проверять подлинность этих веб-сайтов перед вводом своих учётных данных, злоумышленники смогут воспользоваться этой практикой для кражи паролей владельцев ресурсов.
Поставщикам услуг следует стремиться информировать конечных пользователей о рисках, связанных с фишинговыми атаками, и предоставлять механизмы, позволяющие конечным пользователям легко подтверждать подлинность их сайтов. Разработчикам клиентов следует учитывать последствия для безопасности, связанные со способом взаимодействия с пользовательским агентом (например, внешним или встроенным), а также возможность конечного пользователя проверить подлинность сервера авторизации.
Для снижения риска фишинговых атак серверы авторизации ДОЛЖНЫ (MUST) требовать использования TLS на каждой конечной точке, используемой для взаимодействия с конечными пользователями.
10.12. Подделка межсайтовых запросов
Подделка межсайтовых запросов (CSRF) — это способ эксплуатации уязвимости, при котором злоумышленник заставляет пользовательский агент конечного пользователя — жертвы перейти по вредоносному URI (например, предоставленному пользовательскому агенту в виде вводящей в заблуждение ссылки, изображения или перенаправления) на сервер, который доверяет этому агенту (обычно доверие устанавливается по наличию действительного сеансового cookie).
CSRF-атака на URI перенаправления клиента позволяет злоумышленнику внедрить собственный код авторизации или токен доступа, в результате чего клиент может использовать токен доступа, связанный с защищёнными ресурсами злоумышленника, а не жертвы (например, сохранить сведения о банковском счёте жертвы в защищённом ресурсе, контролируемом злоумышленником).
Клиент ДОЛЖЕН (MUST) реализовать защиту от CSRF для своего URI перенаправления. Обычно для этого требуется, чтобы любой запрос, отправляемый на конечную точку URI перенаправления, включал значение, связывающее запрос с аутентифицированным состоянием пользовательского агента (например, хеш сеансового cookie, используемого для аутентификации пользовательского агента). Клиенту СЛЕДУЕТ (SHOULD) использовать параметр запроса "state" для передачи этого значения серверу авторизации при выполнении запроса авторизации.
После получения разрешения от конечного пользователя сервер авторизации перенаправляет пользовательский агент конечного пользователя обратно к клиенту с требуемым значением привязки в параметре "state". Значение привязки позволяет клиенту проверить действительность запроса, сопоставив это значение с аутентифицированным состоянием пользовательского агента. Значение привязки, используемое для защиты от CSRF, ДОЛЖНО (MUST) содержать значение, которое невозможно угадать (как описано в разделе 10.10), а аутентифицированное состояние пользовательского агента (например, сеансовый cookie, локальное хранилище HTML5) ДОЛЖНО (MUST) храниться в месте, доступном только клиенту и пользовательскому агенту (то есть защищённом политикой одинакового источника).
CSRF-атака на конечную точку авторизации сервера авторизации может привести к тому, что злоумышленник получит разрешение конечного пользователя для вредоносного клиента без участия или уведомления конечного пользователя.
Сервер авторизации ДОЛЖЕН (MUST) реализовать защиту от CSRF для своей конечной точки авторизации и обеспечить невозможность получения разрешения вредоносным клиентом без ведома и явного согласия владельца ресурса.
10.13. Кликджекинг
При атаке с использованием кликджекинга злоумышленник регистрирует легитимного клиента, а затем создаёт вредоносный сайт, на котором загружает веб-страницу конечной точки авторизации сервера авторизации в прозрачный iframe, наложенный поверх набора подставных кнопок, тщательно размещённых непосредственно под важными кнопками страницы авторизации. Когда конечный пользователь нажимает вводящую в заблуждение видимую кнопку, в действительности он нажимает невидимую кнопку на странице авторизации (например, кнопку "Authorize"). Это позволяет злоумышленнику обманом заставить владельца ресурса предоставить доступ клиенту злоумышленника без ведома конечного пользователя.
Для предотвращения этой формы атаки нативным приложениям СЛЕДУЕТ (SHOULD) использовать внешние браузеры вместо встраивания браузеров в приложение при запросе разрешения конечного пользователя. Для большинства более новых браузеров сервер авторизации может принудительно запретить использование iframe с помощью (нестандартного) заголовка "x-frame-options". Этот заголовок может иметь два значения: "deny" и "sameorigin", которые блокируют любое размещение во фрейме либо размещение во фрейме сайтами с другим источником соответственно. Для более старых браузеров можно использовать методы JavaScript, препятствующие размещению во фреймах, однако они могут быть эффективны не во всех браузерах.
10.14. Внедрение кода и проверка входных данных
Атака с внедрением кода происходит, когда приложение использует входную переменную или переменную иного внешнего происхождения без обезвреживания её содержимого, что приводит к изменению логики приложения. Это может позволить злоумышленнику получить доступ к устройству, на котором работает приложение, или к его данным, вызвать отказ в обслуживании либо вызвать широкий спектр вредоносных побочных эффектов.
Сервер авторизации и клиент ДОЛЖНЫ (MUST) обезвреживать содержимое любого полученного значения (и проверять его, когда это возможно), в частности значения параметров "state" и "redirect_uri".
10.15. Открытые перенаправители
Сервер авторизации, конечная точка авторизации и конечная точка перенаправления клиента могут быть настроены неправильно и работать как открытые перенаправители. Открытый перенаправитель — это конечная точка, использующая параметр для автоматического перенаправления пользовательского агента в место, указанное значением параметра, без какой-либо проверки.
Открытые перенаправители могут использоваться в фишинговых атаках либо применяться злоумышленником, чтобы побудить конечных пользователей посещать вредоносные сайты, используя компонент authority в URI знакомого и доверенного адресата. Кроме того, если сервер авторизации позволяет клиенту зарегистрировать только часть URI перенаправления, злоумышленник может использовать открытый перенаправитель, управляемый
клиентом, для создания URI перенаправления, который пройдёт проверку сервера авторизации, но отправит код авторизации или токен доступа на конечную точку, контролируемую злоумышленником.
10.16. Злоупотребление токеном доступа для выдачи себя за владельца ресурса в неявном процессе
Для публичных клиентов, использующих неявные процессы, эта спецификация не предоставляет никакого способа определить, какому клиенту был выдан токен доступа.
Владелец ресурса может добровольно делегировать доступ к ресурсу, предоставив токен доступа вредоносному клиенту злоумышленника. Это может произойти вследствие фишинга или под каким-либо другим предлогом. Злоумышленник также может украсть токен с помощью какого-либо другого механизма. Затем злоумышленник может попытаться выдать себя за владельца ресурса, предоставив токен доступа легитимному публичному клиенту.
В неявном процессе (response_type=token) злоумышленник может легко подменить токен в ответе сервера авторизации, заменив настоящий токен доступа токеном, ранее выданным злоумышленнику.
Серверы, взаимодействующие с нативными приложениями и полагающиеся на передачу им токена доступа по обратному каналу для идентификации пользователя клиента, могут быть аналогичным образом скомпрометированы злоумышленником, создавшим скомпрометированное приложение, способное внедрять произвольные украденные токены доступа.
Любой публичный клиент, предполагающий, что только владелец ресурса может предъявить ему действительный токен доступа к ресурсу, уязвим для этого типа атак.
Этот тип атак может раскрыть злоумышленнику (вредоносному клиенту) сведения о владельце ресурса, имеющиеся у легитимного клиента. Это также позволит злоумышленнику выполнять операции у легитимного клиента с теми же разрешениями, что и владелец ресурса, который первоначально предоставил токен доступа или код авторизации.
Аутентификация владельцев ресурсов перед клиентами выходит за рамки этой спецификации. Любая спецификация, использующая процесс авторизации как форму делегированной аутентификации конечного пользователя перед клиентом (например, служба входа через третью сторону), НЕ ДОЛЖНА (MUST NOT) использовать неявный процесс без дополнительных механизмов безопасности, которые позволяли бы клиенту определить, был ли токен доступа выдан для использования этим клиентом (например, путём ограничения круга получателей токена доступа).
11.1. Реестр типов токенов доступа OAuth
Настоящая спецификация учреждает реестр OAuth Access Token Types.
Типы токенов доступа регистрируются согласно процедуре Specification Required ([RFC5226]) после двухнедельного периода рассмотрения в списке рассылки oauth-ext-review@ietf.org по рекомендации одного или нескольких назначенных экспертов (Designated Experts). Однако, чтобы обеспечить возможность выделения значений до публикации, назначенные эксперты могут одобрить регистрацию, как только убедятся, что такая спецификация будет опубликована.
Заявки на регистрацию должны направляться в список рассылки oauth-ext-review@ietf.org для рассмотрения и комментирования с соответствующей темой сообщения (например, "Request for access token type: example").
В течение периода рассмотрения назначенные эксперты одобряют или отклоняют заявку на регистрацию, сообщая это решение в список рассылки для рассмотрения и в IANA. Отказы следует сопровождать объяснением и, если применимо, предложениями о том, как добиться одобрения заявки.
IANA должна принимать обновления реестра только от назначенных экспертов, и ей следует направлять все заявки на регистрацию в список рассылки для рассмотрения.
11.1.1. Шаблон регистрации
Имя типа:
Запрашиваемое имя (например, "example").
Дополнительные параметры ответа конечной точки токенов:
Дополнительные параметры ответа, возвращаемые вместе с параметром "access_token". Новые параметры ДОЛЖНЫ (MUST) отдельно регистрироваться в реестре OAuth Parameters, как описано в разделе 11.2.
Схемы аутентификации HTTP:
Имена схем аутентификации HTTP, если такие имеются, используемых для аутентификации запросов к защищённым ресурсам с помощью токенов доступа этого типа.
Сторона, ответственная за изменения:
Для RFC категории Standards Track укажите "IETF". Для остальных укажите имя ответственной стороны. Можно также включить другие сведения (например, почтовый адрес, адрес электронной почты, URI домашней страницы).
Документы спецификации:
Ссылка на документы, определяющие параметр, предпочтительно с URI, по которому можно получить копию этих документов. Можно также включить указание соответствующих разделов, но это не обязательно.
11.2. Реестр OAuth Parameters
Настоящая спецификация учреждает реестр OAuth Parameters.
Дополнительные параметры для включения в запрос к конечной точке авторизации, ответ конечной точки авторизации, запрос к конечной точке токенов или ответ конечной точки токенов регистрируются согласно процедуре Specification Required ([RFC5226]) после двухнедельного периода рассмотрения в списке рассылки oauth-ext-review@ietf.org по рекомендации одного или нескольких назначенных экспертов. Однако, чтобы обеспечить возможность выделения значений до публикации, назначенные эксперты могут одобрить регистрацию, как только убедятся, что такая спецификация будет опубликована.
Заявки на регистрацию должны направляться в список рассылки oauth-ext-review@ietf.org для рассмотрения и комментирования с соответствующей темой сообщения (например, "Request for parameter: example").
В течение периода рассмотрения назначенные эксперты одобряют или отклоняют заявку на регистрацию, сообщая это решение в список рассылки для рассмотрения и в IANA. Отказы следует сопровождать объяснением и, если применимо, предложениями о том, как добиться одобрения заявки.
IANA должна принимать обновления реестра только от назначенных экспертов, и ей следует направлять все заявки на регистрацию в список рассылки для рассмотрения.
11.2.1. Шаблон регистрации
Имя параметра:
Запрашиваемое имя (например, "example").
Место использования параметра:
Места, где может использоваться параметр. Возможные места: запрос авторизации, ответ авторизации, запрос токена или ответ с токеном.
Сторона, ответственная за изменения:
Для RFC категории Standards Track укажите "IETF". Для остальных укажите имя ответственной стороны. Можно также включить другие сведения (например, почтовый адрес, адрес электронной почты, URI домашней страницы).
Документы спецификации:
Ссылка на документы, определяющие параметр, предпочтительно с URI, по которому можно получить копию этих документов. Можно также включить указание соответствующих разделов, но это не обязательно.
11.2.2. Начальное содержимое реестра
Начальное содержимое реестра OAuth Parameters:
o Имя параметра: client_id
o Место использования параметра: authorization request, token request
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя параметра: client_secret
o Место использования параметра: token request
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя параметра: response_type
o Место использования параметра: authorization request
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя параметра: redirect_uri
o Место использования параметра: authorization request, token request
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя параметра: scope
o Место использования параметра: authorization request, authorization response, token request, token response
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя параметра: state
o Место использования параметра: authorization request, authorization response
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя параметра: code
o Место использования параметра: authorization response, token request
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя параметра: error_description
o Место использования параметра: authorization response, token response
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя параметра: error_uri
o Место использования параметра: authorization response, token response
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя параметра: grant_type
o Место использования параметра: token request
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя параметра: access_token
o Место использования параметра: authorization response, token response
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя параметра: token_type
o Место использования параметра: authorization response, token response
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя параметра: expires_in
o Место использования параметра: authorization response, token response
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя параметра: username
o Место использования параметра: token request
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя параметра: password
o Место использования параметра: token request
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя параметра: refresh_token
o Место использования параметра: token request, token response
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
11.3. Реестр OAuth Authorization Endpoint Response Types
Настоящая спецификация учреждает реестр OAuth Authorization Endpoint Response Types.
Дополнительные типы ответов для использования с конечной точкой авторизации регистрируются согласно процедуре Specification Required ([RFC5226]) после двухнедельного периода рассмотрения в списке рассылки oauth-ext-review@ietf.org по рекомендации одного или нескольких назначенных экспертов. Однако, чтобы обеспечить возможность выделения значений до публикации, назначенные эксперты могут одобрить регистрацию, как только убедятся, что такая спецификация будет опубликована.
Заявки на регистрацию должны направляться в список рассылки oauth-ext-review@ietf.org для рассмотрения и комментирования с соответствующей темой сообщения (например, "Request for response type: example").
В течение периода рассмотрения назначенные эксперты одобряют или отклоняют заявку на регистрацию, сообщая это решение в список рассылки для рассмотрения и в IANA. Отказы следует сопровождать объяснением и, если применимо, предложениями о том, как добиться одобрения заявки.
IANA должна принимать обновления реестра только от назначенных экспертов, и ей следует направлять все заявки на регистрацию в список рассылки для рассмотрения.
11.3.1. Шаблон регистрации
Имя типа ответа:
Запрашиваемое имя (например, "example").
Сторона, ответственная за изменения:
Для RFC категории Standards Track укажите "IETF". Для остальных укажите имя ответственной стороны. Можно также включить другие сведения (например, почтовый адрес, адрес электронной почты, URI домашней страницы).
Документы спецификации:
Ссылка на документы, определяющие тип, предпочтительно с URI, по которому можно получить копию этих документов. Можно также включить указание соответствующих разделов, но это не обязательно.
11.3.2. Начальное содержимое реестра
Начальное содержимое реестра OAuth Authorization Endpoint Response Types:
o Имя типа ответа: code
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
o Имя типа ответа: token
o Сторона, ответственная за изменения: IETF
o Документы спецификации: RFC 6749
11.4. Реестр OAuth Extensions Error
Настоящая спецификация учреждает реестр OAuth Extensions Error.
Дополнительные коды ошибок, используемые совместно с другими расширениями протокола (то есть типами предоставления полномочий, определёнными расширениями, типами токенов доступа или параметрами расширений), регистрируются согласно процедуре Specification Required ([RFC5226]) после двухнедельного периода рассмотрения в списке рассылки oauth-ext-review@ietf.org по рекомендации одного или нескольких назначенных экспертов. Однако, чтобы обеспечить возможность выделения значений до публикации, назначенные эксперты могут одобрить регистрацию, как только убедятся, что такая спецификация будет опубликована.
Заявки на регистрацию должны направляться в список рассылки oauth-ext-review@ietf.org для рассмотрения и комментирования с соответствующей темой сообщения (например, "Request for error code: example").
В течение периода рассмотрения назначенные эксперты одобряют или отклоняют заявку на регистрацию, сообщая это решение в список рассылки для рассмотрения и в IANA. Отказы следует сопровождать объяснением и, если применимо, предложениями о том, как добиться одобрения заявки.
IANA должна принимать обновления реестра только от назначенных экспертов, и ей следует направлять все заявки на регистрацию в список рассылки для рассмотрения.
11.4.1. Шаблон регистрации
Имя ошибки:
Запрашиваемое имя (например, "example"). Значения имени ошибки НЕ ДОЛЖНЫ (MUST NOT) включать символы вне набора %x20-21 / %x23-5B / %x5D-7E.
Место использования ошибки:
Места, где может использоваться ошибка. Возможные места: ответ с ошибкой при предоставлении полномочий посредством кода авторизации (раздел 4.1.2.1), ответ с ошибкой при неявном предоставлении полномочий (раздел 4.2.2.1), ответ с ошибкой при запросе токена (раздел 5.2) или ответ с ошибкой доступа к ресурсу (раздел 7.2).
Связанное расширение протокола:
Имя типа предоставления полномочий, определённого расширением, типа токена доступа или параметра расширения, совместно с которым используется код ошибки.
Сторона, ответственная за изменения:
Для RFC категории Standards Track укажите "IETF". Для остальных укажите имя ответственной стороны. Можно также включить другие сведения (например, почтовый адрес, адрес электронной почты, URI домашней страницы).
Документы спецификации:
Ссылка на документы, определяющие код ошибки, предпочтительно с URI, по которому можно получить копию этих документов. Можно также включить указание соответствующих разделов, но это не обязательно.
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", В процессе разработки, February 2012.
[OAuth-SAML2]
Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion
Profiles for OAuth 2.0", В процессе разработки, September 2012.
[OAuth-THREATMODEL]
Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", В процессе
разработки, October 2012.
[OAuth-WRAP]
Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth
Web Resource Authorization Profiles", В процессе разработки,
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], но из него исключены символы
возврата каретки и перевода строки.)
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 и 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
(<http://www.iana.org/assignments/media-types>). Кроме того, это
определение неполно, поскольку не учитывает символы, не входящие
в US-ASCII.
Чтобы устранить этот недостаток при формировании полезной нагрузки
с использованием данного типа данных, имена и значения ДОЛЖНЫ (MUST)
сначала кодироваться с использованием схемы кодирования символов
UTF-8 [RFC3629]; затем полученную последовательность октетов необходимо
дополнительно кодировать с использованием правил экранирования,
определённых в [W3C.REC-html401-19991224].
При разборе данных из полезной нагрузки, использующей этот тип данных,
имена и значения, полученные в результате обращения кодирования
имён и значений, соответственно, необходимо рассматривать как
последовательности октетов, подлежащие декодированию с использованием
схемы кодирования символов UTF-8.
Например, значение, состоящее из шести кодовых точек Unicode:
(1) U+0020 (пробел), (2) U+0025 (знак процента),
(3) U+0026 (амперсанд), (4) U+002B (знак плюса),
(5) U+00A3 (знак фунта) и (6) U+20AC (знак евро), было бы закодировано
в следующую последовательность октетов (в шестнадцатеричной записи):
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.