RFC 8252 | OAuth 2.0 для собственных приложений

Аннотация

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

Скачать оригинальный документ на английском языке RFC 8252 PDF

Оглавление

1. Введение
2. Условные обозначения
3. Терминология
4. Обзор
4.1. Поток авторизации для собственных приложений с использованием браузера
5. Использование Inter-App URI коммуникацию для OAuth
6. Инициирование запроса авторизации из собственного приложения
7. Получение ответа на авторизацию в собственном приложении
7.1. Частное перенаправление схемы URI
7.2. Заявленное перенаправление URI схемы «https»
7.3. Перенаправление интерфейса Loopback
8. Вопросы безопасности
8.1. Защита кода авторизации
8.2. Поток авторизации неявного предоставления OAuth
8.3. Соображения о перенаправлении петли
8.4. Регистрация нативных клиентов приложения
8.5. Аутентификация клиента
8.6. Олицетворение клиента
8.7. Поддельные внешние агенты пользователя
8.8. Вредоносные внешние пользовательские агенты
8.9. Защита от подделки запросов между приложениями
8.10. Смягчение путаницы на сервере авторизации
8.11. Внешние пользовательские агенты без браузера
8.12. Встроенные пользовательские агенты
9. Соображения IANA
10. Ссылки
10.1. Нормативные ссылки
10.2. Информационные ссылки
Приложение A. Контрольный список поддержки сервера
Приложение B. Детали реализации для платформы
B.1. Детали реализации iOS
В.2. Детали реализации Android
В.3. Детали реализации Windows
В.4. Детали реализации macOS
В.5. Детали реализации Linux
Благодарности
Адреса авторов

1. Введение

В разделе 9 инфраструктуры авторизации OAuth 2.0 [RFC6749] описаны два подхода для взаимодействия собственных приложений с конечной точкой авторизации: встроенный пользовательский агент и внешний пользовательский агент.

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

Эта практика также известна как «шаблон AppAuth» со ссылкой на библиотеки с открытым исходным кодом [AppAuth], которые его реализуют.

2. Условные обозначения

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119] [RFC8174].

3. Терминология

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

native app — (App или Application) — это собственное приложение, которое пользователь устанавливает на свое устройство, в отличие от веб-приложения, которое работает только в контексте браузера. Приложения, реализованные с использованием веб-технологий, но распространяемые как собственные приложения, так называемые «гибридные приложения», считаются эквивалентными собственным приложениям для целей данной спецификации.

app — «Нативное приложение», если не указано иное.

app store — Интернет-магазин, где пользователи могут загружать и покупать приложения.

OAuth — Протокол авторизации, указанный в OAuth 2.0 Framework Authorization Framework [RFC6749 #].

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

embedded user-agent — встроенный пользовательский агент — это пользовательский агент, размещенный в собственном приложении, создающий запрос авторизации, который является частью приложения или совместно использует тот же домен безопасности, так что приложение может получить доступ к хранилищу cookie и/или проверить или изменить содержимое страницы.

browser — Приложение по умолчанию, запускаемое операционной системой для обработки содержимого URI схемы «http» и «https».

in-app browser tab — Программный экземпляр браузера, который отображается внутри хост-приложения, но сохраняет все свойства безопасности и состояние аутентификации браузера. У него разные названия продуктов для разных платформ, некоторые из которых подробно описаны в Приложении B.

web-view — Компонент UI (пользовательского интерфейса) веб-браузера, который встроен в приложения для отображения веб-страниц под управлением приложения.

inter-app communication — Связь между двумя приложениями на устройстве.

claimed «https» scheme URI — Некоторые платформы позволяют приложениям запрашивать URI схемы «https» после подтверждения права собственности на доменное имя. URI, заявленные таким образом, затем открываются в приложении, а не в браузере.

private-use URI scheme — В данном документе используется схема URI, определенная приложением (в соответствии с требованиями раздела 3.8 [RFC7595]) и зарегистрированная в операционной системе. Запросы URI к таким схемам запускают приложение, которое зарегистрировало его для обработки запроса.

reverse domain name notation — Соглашение об именах, основанное на системе доменных имен, но в которой компоненты домена обращены, например, «app.example.com», становится «com.example.app».

4. Обзор

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

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

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

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

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

Рисунок 1 - Нативная авторизация приложения через внешнего агента пользователя
Рисунок 1 — Нативная авторизация приложения через внешнего агента пользователя

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

  1. Клиентское приложение открывает вкладку браузера с запросом авторизации.
  2. Конечная точка авторизации получает запрос авторизации, аутентифицирует пользователя и получает авторизацию. Аутентификация пользователя может включать связывание с другими системами аутентификации.
  3. Сервер авторизации выдает код авторизации для URI перенаправления.
  4. Клиент получает код авторизации от URI перенаправления.
  5. Клиентское приложение представляет код авторизации в конечной точке токена.
  6. Конечная точка токена проверяет код авторизации и выдает запрошенные токены.

5. Использование Inter-App URI Communication для OAuth

Точно так же, как URI используются для OAuth 2.0 [RFC6749] в Интернете для инициирования запроса авторизации и возврата ответа на запрос авторизации на веб-сайт запрашивающего сайта, URI могут использоваться собственными приложениями для инициирования запроса авторизации в браузере устройства и возврата ответа на запрос. запрашивающее нативное приложение.

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

Чтобы соответствовать этому передовому опыту, нативные приложения ДОЛЖНЫ использовать внешний пользовательский агент для выполнения запросов на авторизацию OAuth. Это достигается открытием запроса авторизации в браузере (подробно описано в Разделе 6) и использованием URI перенаправления, который возвращает ответ авторизации обратно в собственное приложение (определено в Разделе 7).

6. Инициирование запроса авторизации из собственного приложения

Родные приложения, которым требуется авторизация пользователя, создают URI запроса авторизации с типом предоставления кода авторизации в соответствии с разделом 4.1 OAuth 2.0 [RFC6749], используя URI перенаправления, который может быть получен собственным приложением.

Функция URI перенаправления для собственного запроса авторизации приложения аналогична функции веб-запроса авторизации. Вместо того, чтобы возвращать ответ авторизации на сервер клиента OAuth, URI перенаправления, используемый собственным приложением, возвращает ответ приложению. Несколько вариантов для URI перенаправления, который будет возвращать ответ авторизации для собственного приложения на разных платформах, описаны в разделе 7. Любой URI перенаправления, который позволяет приложению получать URI и проверять его параметры, является жизнеспособным.

Общедоступные нативные клиенты приложений ДОЛЖНЫ реализовывать расширение Proof Key for Code Exchange (PKCE [RFC7636]) для OAuth, и серверы авторизации ДОЛЖНЫ поддерживать PKCE для таких клиентов по причинам, подробно изложенным в разделе 8.1.

После создания URI запроса авторизации приложение использует API-интерфейсы платформы для открытия URI во внешнем агенте пользователя. Как правило, используемый внешний пользовательский агент является браузером по умолчанию, то есть приложением, настроенным для обработки URI-адресов схемы «http» и «https» в системе; однако МОГУТ использоваться другие критерии выбора браузера и другие категории внешних пользовательских агентов.

Эта лучшая практика фокусируется на браузере как РЕКОМЕНДУЕМОМ внешнем пользовательском агенте для собственных приложений. МОЖЕТ также использоваться внешний пользовательский агент, разработанный специально для авторизации пользователя и способный обрабатывать запросы и ответы на авторизацию, такие как браузер. Другие внешние пользовательские агенты, такие как собственное приложение, предоставляемое сервером авторизации, могут соответствовать критериям, изложенным в этой лучшей практике, включая использование тех же свойств URI перенаправления, но их использование выходит за рамки данной спецификации.

Некоторые платформы поддерживают функцию браузера, известную как «вкладки браузера в приложении», где приложение может представлять вкладку браузера в контексте приложения, не переключая приложения, но при этом сохраняя ключевые преимущества браузера, такие как общее состояние аутентификации и безопасность. контекст. На платформах, где они поддерживаются, РЕКОМЕНДУЕТСЯ, из соображений удобства использования, приложения используют вкладки браузера в приложении для запроса авторизации.

7. Получение ответа на авторизацию в собственном приложении

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

Для полной поддержки этой передовой практики серверы авторизации ДОЛЖНЫ предлагать как минимум три параметра URI перенаправления, описанные в следующих подразделах для собственных приложений. Нативные приложения МОГУТ использовать любую опцию перенаправления, которая наилучшим образом соответствует их потребностям, принимая во внимание детали реализации для конкретной платформы.

7.1. Частное перенаправление схемы URI

Многие мобильные и настольные вычислительные платформы поддерживают взаимодействие между приложениями через URI, позволяя приложениям регистрировать схемы URI частного использования (иногда в разговорной речи называемые «пользовательскими схемами URL»), например «com.example.app». Когда браузер или другое приложение пытается загрузить URI с использованием схемы URI для частного использования, приложение, которое зарегистрировало его, запускается для обработки запроса.

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

При выборе схемы URI для связи с приложением приложения ДОЛЖНЫ использовать схему URI, основанную на доменном имени, находящемся под их контролем, в обратном порядке, как рекомендовано в разделе 3.8 [RFC7595] для схем URI частного использования.

Например, приложение, которое контролирует доменное имя «app.example.com», может использовать «com.example.app» в качестве своей схемы. Некоторые серверы авторизации назначают идентификаторы клиентов на основе доменных имен, например, «client1234.usercontent.example.net», которые также могут использоваться в качестве доменного имени для схемы при обращении таким же образом. Однако такая схема, как «myapp», не отвечает этому требованию, поскольку она не основана на доменном имени.

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

В соответствии с требованиями Раздела 3.2 [RFC3986], поскольку нет полномочий по присвоению имен для перенаправлений схемы URI частного использования, после компонента схемы появляется только одна косая черта («/»). Полный пример URI перенаправления, использующего схему URI частного использования:

com.example.app:/oauth2redirect/example-provider

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

7.2. Заявленное перенаправление URI схемы «https»

Некоторые операционные системы позволяют приложениям запрашивать URI схемы «https» [RFC7230] в доменах, которыми они управляют. Когда браузер обнаруживает заявленный URI, вместо страницы, загружаемой в браузер, собственное приложение запускается с URI, предоставленным в качестве параметра запуска.

Такие URI могут использоваться в качестве URI перенаправления нативными приложениями. Они неотличимы от сервера авторизации от обычного веб-клиента перенаправления URI. Примером является:

https://app.example.com/oauth2redirect/example-provider

Поскольку одного URI перенаправления недостаточно для того, чтобы отличить общедоступные собственные клиенты приложений от конфиденциальных веб-клиентов, в разделе 8.4 ТРЕБУЕТСЯ, чтобы тип клиента записывался во время регистрации клиента, чтобы сервер мог определить тип клиента и действовать соответствующим образом.

Утверждаемые приложением URI-адреса перенаправления схемы «https» имеют некоторые преимущества по сравнению с другими собственными параметрами перенаправления приложений в том смысле, что операционная система гарантирует серверу авторизации идентичность целевого приложения. По этой причине нативные приложения ДОЛЖНЫ использовать их поверх других опций, где это возможно.

7.3. Перенаправление интерфейса Loopback

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

URI перенаправления с обратной связью используют схему «http» и создаются с использованием IP-литера обратной связи и любого порта, который прослушивает клиент. То есть, «http://127.0.0.1:{port}/{path}» для IPv4 и «http://[::1]:{port}/{path}» для IPv6. Пример перенаправления с использованием интерфейса обратной связи IPv4 со случайно назначенным портом:

http://127.0.0.1:51004/oauth2redirect/example-provider

Пример перенаправления с использованием интерфейса обратной связи IPv6 со случайно назначенным портом:

http://[::1]:61023/oauth2redirect/example-provider

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

Клиентам НЕ СЛЕДУЕТ предполагать, что устройство поддерживает определенную версию интернет-протокола. РЕКОМЕНДУЕТСЯ, чтобы клиенты пытались подключиться к интерфейсу обратной связи, используя как IPv4, так и IPv6, и использовать то, что доступно.

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

8.1. Защита кода авторизации

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

Ограничение использования схем URI частного использования для URI перенаправления состоит в том, что несколько приложений обычно могут регистрировать одну и ту же схему, что делает ее неопределенной в отношении того, какое приложение получит код авторизации. В разделе 1 PKCE [RFC7636] подробно описано, как это ограничение можно использовать для выполнения атаки перехвата кода.

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

Заявленные приложением перенаправления схемы «https» менее восприимчивы к перехвату URI из-за наличия полномочий URI, но приложение все еще является общедоступным клиентом; кроме того, URI отправляется с использованием обработчика отправки URI операционной системы с неизвестными свойствами безопасности.

Протокол PKCE [RFC7636] был создан специально для предотвращения этой атаки. Это расширение для подтверждения владения OAuth 2.0, которое защищает код авторизации от использования в случае его перехвата. Чтобы обеспечить защиту, у этого расширения клиент генерирует секретный верификатор; он передает хэш этого верификатора в первоначальном запросе авторизации и должен представить не хэшированный верификатор при погашении кода авторизации. Приложение, которое перехватило код авторизации, не будет обладать этим секретом, что делает код бесполезным.

Раздел 6 требует, чтобы и клиенты, и серверы использовали PKCE для общедоступных собственных клиентов приложений. Серверы авторизации ДОЛЖНЫ отклонять запросы авторизации от собственных приложений, которые не используют PKCE, возвращая сообщение об ошибке, как определено в Разделе 4.4.1 PKCE [RFC7636].

8.2. Поток авторизации неявного предоставления OAuth

Поток авторизации неявного предоставления OAuth 2.0 (определенный в Разделе 4.2 OAuth 2.0 [RFC6749]) обычно работает с практикой выполнения запроса авторизации в браузере и получения ответа на авторизацию посредством связи между приложениями на основе URI. Однако, поскольку неявный поток не может быть защищен PKCE [RFC7636] (что требуется в разделе 8.1), использование неявного потока с собственными приложениями НЕ РЕКОМЕНДУЕТСЯ.

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

8.3. Соображения о перенаправлении петли

URI перенаправления интерфейса с обратной связью используют схему «http» (т. е. без безопасности транспортного уровня (TLS)). Это приемлемо для URI перенаправления интерфейса обратной связи, поскольку HTTP-запрос никогда не покидает устройство.

Клиенты должны открывать сетевой порт только при запуске запроса на авторизацию и закрывать его после возврата ответа.

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

В то время как URI перенаправления с использованием localhost (то есть, «http: // localhost: {port} / {path}») функционируют аналогично петлевым IP-перенаправлениям, описанным в Разделе 7.3, использование localhost НЕ РЕКОМЕНДУЕТСЯ. Указание URI перенаправления с литералом IP обратной петли, а не с localhost, позволяет избежать случайного прослушивания сетевых интерфейсов, отличных от интерфейса обратной связи. Он также менее восприимчив к брандмауэрам на стороне клиента и неверно настроенному разрешению имен хостов на устройстве пользователя.

8.4. Регистрация нативных клиентов приложения

За исключением случаев использования механизма, такого как динамическая регистрация клиентов [RFC7591], для предоставления секретов для каждого экземпляра, собственные приложения классифицируются как публичные клиенты, как определено в разделе 2.1 OAuth 2.0 [RFC6749]; они ДОЛЖНЫ быть зарегистрированы на сервере авторизации как таковом. Серверы авторизации ДОЛЖНЫ записывать тип клиента в сведениях о регистрации клиента, чтобы соответственно идентифицировать и обрабатывать запросы.

Серверы авторизации ДОЛЖНЫ требовать, чтобы клиенты регистрировали свой полный URI перенаправления (включая компонент пути), и отклоняли запросы на авторизацию, в которых указан URI перенаправления, который не совсем соответствует тому, который был зарегистрирован; Исключением являются петлевые перенаправления, где требуется точное соответствие, за исключением компонента URI порта.

Для переадресаций на основе схем URI для частного использования серверам авторизации СЛЕДУЕТ применять требование Раздела 7.1 о том, что клиенты используют схемы, основанные на обратном доменном имени. Как минимум, любая схема URI для частного использования, которая не содержит символа точки («.»), ДОЛЖНА быть отклонена.

В дополнение к свойствам защиты от столкновений требование схемы URI, основанной на доменном имени, которое находится под контролем приложения, может помочь подтвердить право собственности в случае спора, когда два приложения требуют одну и ту же схему URI частного использования (где одно приложение действует злонамеренно). Например, если два приложения заявили «com.example.app», владелец «example.com» может обратиться к оператору магазина приложений с просьбой удалить поддельное приложение. Такую петицию сложнее доказать, если использовалась общая схема URI.

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

8.5. Аутентификация клиента

Секреты, которые статически включены как часть приложения, распространяемого среди нескольких пользователей, не должны рассматриваться как конфиденциальные секреты, так как один пользователь может проверить свою копию и узнать общий секрет. По этой причине и тем, которые указаны в Разделе 5.3.1 [RFC6819], для серверов авторизации НЕ РЕКОМЕНДУЕТСЯ требовать аутентификации клиента общедоступных клиентов собственных приложений, использующих общий секрет, так как это служит небольшим значением помимо идентификации клиента, которая уже предоставлена. по параметру запроса «client_id».

Серверы авторизации, которым все еще требуется статически включенный общий секрет для собственных клиентов приложения, ДОЛЖНЫ рассматривать клиента как общедоступного клиента (как определено в разделе 2.1 OAuth 2.0 [RFC6749]) и не принимать секрет в качестве подтверждения личности клиента. Без дополнительных мер такие клиенты могут быть олицетворены (см. Раздел 8.6).

8.6. Олицетворение клиента

Как указано в Разделе 10.2 OAuth 2.0 [RFC6749], серверу авторизации НЕ СЛЕДУЕТ обрабатывать запросы авторизации автоматически без согласия пользователя или взаимодействия, за исключением случаев, когда может быть гарантирована личность клиента. Это включает в себя случай, когда пользователь ранее одобрил запрос авторизации для данного идентификатора клиента — если личность клиента не может быть подтверждена, запрос ДОЛЖЕН обрабатываться так, как если бы предыдущий запрос не был утвержден.

Такие меры, как заявленные перенаправления «https», МОГУТ быть приняты серверами авторизации в качестве подтверждения личности. Некоторые операционные системы могут предлагать альтернативные специфичные для платформы функции идентификации, которые МОГУТ быть приняты в зависимости от обстоятельств.

8.7. Поддельные внешние агенты пользователя

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

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

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

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

8.8. Вредоносные внешние пользовательские агенты

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

Эта атака не ограничивается OAuth; настроенное таким образом вредоносное приложение будет представлять общий и постоянный риск для пользователя, помимо использования OAuth нативными приложениями. Многие операционные системы смягчают эту проблему, требуя явного действия пользователя для изменения обработчика по умолчанию для URI-адресов схемы «http» и «https».

8.9. Защита от подделки запросов между приложениями

В разделе 5.3.5 [RFC6819] рекомендуется использовать параметр «state» для связывания клиентских запросов и ответов для предотвращения атак CSRF (межсайтовая подделка запросов).

Чтобы смягчить атаки в стиле CSRF по каналам связи URI между приложениями (так называемый «подделка запросов между приложениями»), аналогичным образом РЕКОМЕНДУЕТСЯ, чтобы нативные приложения включали безопасное случайное число с высокой энтропией в параметре «state» запроса авторизации. и отклонить любые входящие ответы на авторизацию без значения состояния, которое соответствует ожидающему исходящему запросу на авторизацию.

8.10. Смягчение путаницы на сервере авторизации

Для защиты от скомпрометированного или злонамеренного сервера авторизации, атакующего другой сервер авторизации, используемый тем же приложением, ТРЕБУЕТСЯ, чтобы уникальный URI перенаправления использовался для каждого сервера авторизации, используемого приложением (например, путем изменения компонента пути), и чтобы ответы на авторизацию отклоняются, если URI перенаправления, на который они были получены, не соответствуют URI перенаправления в исходящем запросе авторизации.

Собственное приложение ДОЛЖНО хранить URI перенаправления, использованный в запросе авторизации, с данными сеанса авторизации (то есть вместе с «состоянием» и другими связанными данными) и ДОЛЖНО проверять, что URI, на который был получен ответ авторизации, точно соответствует ему.

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

8.11. Внешние пользовательские агенты без браузера

В соответствии с этой передовой практикой рекомендуется использовать специальный тип внешнего пользовательского агента: браузер пользователя. Другие шаблоны внешних пользовательских агентов также могут быть полезны для безопасного и пригодного для использования OAuth. Этот документ не комментирует эти шаблоны.

8.12. Встроенные пользовательские агенты

В разделе 9 OAuth 2.0 [RFC6749] описаны два подхода для взаимодействия собственных приложений с конечной точкой авторизации. Эта лучшая текущая практика требует, чтобы собственные приложения НЕ ДОЛЖНЫ использовать встроенные пользовательские агенты для выполнения запросов на авторизацию, и позволяет конечным точкам авторизации МОГУТ предпринять шаги для обнаружения и блокировки запросов на авторизацию во встроенных пользовательских агентах. Соображения безопасности для этих требований подробно описаны здесь.

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

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

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

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

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

9. Соображения IANA

Этот документ не требует никаких действий IANA.

Раздел 7.1 определяет, как схемы URI частного использования используются для взаимодействия interpp в потоках протокола OAuth. Этот документ требует в Разделе 7.1, что такие схемы основаны на доменных именах, принадлежащих или назначенных приложению, как рекомендуется в Разделе 3.8 [RFC7595]. В соответствии с разделом 6 [RFC7595] регистрация доменных схем URI в IANA не требуется.

10. Ссылки

10.1. Нормативные ссылки

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[RFC6749] Hardt, D., Ed., «The OAuth 2.0 Authorization Framework», RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.

[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, «Guidelines and Registration Procedures for URI Schemes», BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <https://www.rfc-editor.org/info/rfc7595>.

[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, «Proof Key for Code Exchange by OAuth Public Clients», RFC 7636, DOI 10.17487/RFC7636, September 2015, <https://www.rfc-editor.org/info/rfc7636>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

10.2. Информационные ссылки

[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, «OAuth 2.0 Threat Model and Security Considerations», RFC 6819, DOI 10.17487/RFC6819, January 2013, <https://www.rfc-editor.org/info/rfc6819>.

[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, «OAuth 2.0 Dynamic Client Registration Protocol», RFC 7591, DOI 10.17487/RFC7591, July 2015, <https://www.rfc-editor.org/info/rfc7591>.

[AppAuth] OpenID Connect Working Group, «AppAuth», September 2017, <https://openid.net/code/AppAuth>.

[AppAuth.iOSmacOS] Wright, S., Denniss, W., et al., «AppAuth for iOS and macOS», February 2016, <https://openid.net/code/AppAuth-iOS>.

[AppAuth.Android] McGinniss, I., Denniss, W., et al., «AppAuth for Android», February 2016, <https://openid.net/code/AppAuth-Android>.

[SamplesForWindows] Denniss, W., «OAuth for Apps: Samples for Windows», July 2016, <https://openid.net/code/sample-oauth-apps-for-windows>.

Приложение A. Контрольный список поддержки сервера

Серверы OAuth, которые поддерживают собственные приложения, должны:

  1. Поддержка URI перенаправления схемы частного использования. Это необходимо для поддержки мобильных операционных систем. Смотрите раздел 7.1.
  2. Поддержка «https» схемы перенаправления URI для использования с общедоступными клиентами собственного приложения. Это используется приложениями в современных мобильных операционных системах, которые допускают использование заявленных URI схемы https. Смотрите раздел 7.2.
  3. Поддержка петлевого IP-адреса перенаправления URI. Это необходимо для поддержки настольных операционных систем. Смотрите Раздел 7.3.
  4. Не предполагайте, что нативные клиенты приложений могут хранить секрет. Если секреты распространяются на несколько установок одного и того же собственного приложения, они не должны рассматриваться как конфиденциальные. Смотрите раздел 8.5.
  5. Поддержка PKCE [RFC7636]. Требуется для защиты грантов кода авторизации, отправляемых публичным клиентам по каналам связи между приложениями. См. Раздел 8.1

Приложение B. Детали реализации для платформы

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

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

B.1. Детали реализации iOS

Приложения могут инициировать запрос авторизации в браузере, не покидая приложение пользователем, через класс «SFSafariViewController» или его преемника «SFAuthenticationSession», которые реализуют шаблон вкладки браузера inapp. Safari может использоваться для обработки запросов на старых версиях iOS без функции вкладки браузера в приложении.

Чтобы получить ответ об авторизации, обе схемы частного URI (называемые «настраиваемой схемой URL») перенаправляют, и заявленные URI схемы «https» (известные как «универсальные ссылки») являются приемлемыми вариантами. Приложения могут запрашивать схемы URI для частного использования с ключом «CFBundleURLTypes» в файле списка свойств приложения, «Info.plist» и «https» в схеме URI, используя функцию универсальных ссылок с файлом разрешений в приложении и размещенным файлом ассоциации на домене.

Утвержденные URI схемы «https» являются предпочтительным вариантом перенаправления на iOS 9 и выше из-за доказательства владения, предоставляемого операционной системой.

Полный пример с открытым исходным кодом включен в библиотеку AppAuth для iOS и macOS [AppAuth.iOSmacOS].

В.2. Детали реализации Android

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

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

Для получения ответа на авторизацию схемы URI частного использования широко поддерживаются через Android Implicit Intents. Утвержденные URI перенаправления схемы «https» через Android App Links доступны на Android 6.0 и выше. Оба типа URI перенаправления зарегистрированы в манифесте приложения.

Полный пример с открытым исходным кодом включен в библиотеку AppAuth for Android [AppAuth.Android].

В.3. Детали реализации Windows

Как традиционные приложения, так и приложения универсальной платформы Windows (UWP) могут выполнять запросы авторизации в браузере пользователя. Традиционные приложения обычно используют перенаправление петли для получения ответа на авторизацию, а прослушивание на интерфейсе петли разрешено правилами брандмауэра по умолчанию. При создании петлевого сетевого сокета приложения ДОЛЖНЫ установить параметр сокета «SO_EXCLUSIVEADDRUSE», чтобы другие приложения не связывались с этим сокетом.

Приложения UWP могут использовать перенаправления схемы URI частного использования, чтобы получить ответ авторизации от браузера, который выведет приложение на передний план. Схема URI, известная на платформе как «Активация URI», имеет длину не более 39 символов и может включать «.» символ, что делает возможным использование коротких обратных доменных схем (как требуется в разделе 7.1).

Приложения UWP могут альтернативно использовать API-интерфейс брокера веб-аутентификации в режиме единого входа (SSO), который является внешним агентом пользователя, предназначенным для потоков авторизации. Файлы cookie распределяются между вызовами брокера, но не в браузере, который предпочитает пользователь. Это означает, что пользователю необходимо будет снова войти в систему, даже если у него есть активный сеанс в браузере; но сеанс, созданный в посреднике, будет доступен для последующих приложений, использующих посредник. Персонализация, которую пользователь сделал в своем браузере, например, настройка менеджера паролей, может быть недоступна в брокере. Чтобы квалифицироваться как внешний пользовательский агент, брокер ДОЛЖЕН использоваться в режиме SSO.

Чтобы использовать брокер веб-аутентификации в режиме единого входа, URI перенаправления должен иметь форму «msapp: // {appSID}», где «{appSID}» — это идентификатор безопасности приложения (SID), который можно найти при регистрации приложения. информацию или путем вызова метода «GetCurrentApplicationCallbackUri». В то время как Windows применяет полномочия URI для таких перенаправлений, гарантируя, что только приложение с соответствующим SID может получить ответ в Windows, схема URI может быть запрошена приложениями на других платформах без таких же прав доступа; таким образом, этот тип перенаправления должен рассматриваться аналогично перенаправлениям схемы URI частного использования в целях безопасности.

Образец с открытым исходным кодом, демонстрирующий эти шаблоны, доступен [SamplesForWindows].

В.4. Детали реализации macOS

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

Для получения ответа на авторизацию схемы URI для частного использования являются хорошим выбором для перенаправления URI в macOS, поскольку пользователь возвращается обратно в приложение, из которого он запустил запрос. Они регистрируются в списке свойств информации о пакете приложения с помощью ключа «CFBundleURLSchemes». Петлевые IP-перенаправления являются еще одним жизнеспособным вариантом, и прослушивание по петлевому интерфейсу разрешено правилами брандмауэра по умолчанию.

Полный пример с открытым исходным кодом включен в библиотеку AppAuth для iOS и macOS [AppAuth.iOSmacOS].

В.5. Детали реализации Linux

Открытие запроса на авторизацию в браузере пользователя по умолчанию требует специальной команды: один из таких инструментов — «xdg-open».

Циклическое перенаправление является рекомендуемым вариантом перенаправления для настольных приложений в Linux, чтобы получить ответ авторизации. Приложениям НЕ СЛЕДУЕТ устанавливать параметры сокетов «SO_REUSEPORT» или «SO_REUSEADDR», чтобы другие приложения не связывались с этим сокетом.

Благодарности

Авторы хотели бы поблагодарить Мариуса Скуртеску (Marius Scurtescu) и Бена Уайли Ситтлера (Ben Wiley Sittler), чей дизайн для использования URI-схем частного использования в клиентах OAuth 2.0 для нативных приложений в Google лег в основу Раздела 7.1.

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

Энди Змолек (Andy Zmolek), Стивен Е. Райт (Steven E. Wright), Брайан Кэмпбелл (Brian Campbell), Нат Сакимура (Nat Sakimura), Эрик Сакс (Eric
Sachs), Пол Мэдсен (Paul Madsen), Иэн Макгиннисс (Iain McGinniss), Рахул Равикумар (Rahul Ravikumar), Брено де Медейрос (Breno de
Medeiros), Ханнес Чофениг (Hannes Tschofenig), Ашиш Джейн (Ashish Jain), Эрик Уолстром (Erik Wahlstrom), Билл Фишер (Bill
Fisher), Судхи Умарджи (Sudhi Umarji), Майкл Б. Джонс (Michael B. Jones), Витторио Берточчи (Vittorio Bertocci), Дик Хардт (Dick
Hardt), Дэвид Уэйт (David Waite), Игнасио Фиорентино (Ignacio Fiorentino), Кэтлин Мориарти (Kathleen Moriarty) и Элвин Дэвис (Elwyn
Davies).

Адреса авторов

William Denniss
Google
1600 Amphitheatre Pkwy
Mountain View, CA 94043
United States of America
Email: rfc8252@wdenniss.com
URI: http://wdenniss.com/appauth

John Bradley
Ping Identity
Phone: +1 202-630-5272
Email: rfc8252@ve7jtb.com
URI: http://www.thread-safe.com/p/appauth.html

Поделись записью