Что's право авторизации OAuth 2.0 для мобильного приложения

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

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

Однако, этот поток, кажется, в значительной степени полагаться на веб-браузер для выполнения перенаправления. Мне интересно, если этот поток все-таки хороший вариант для мобильного приложения при использовании встроенного веб-браузера. Или я должен идти с неявным потоком ?

Dherik
Редактировал вопрос 10-го октября 2019 в 2:28
Программирование
security mobile oauth-2.0
2-го июля 2013 в 2:04
39 просмотров
Комментарии к вопросу (4)

Уточнение: Мобильное Приложение = Приложение Как указано в других комментариях и через несколько интернет-источников, неявные кажется естественным, пригодный для мобильных приложений, однако лучшее решение не всегда четкие (а на самом деле подразумевается не рекомендуется по причинам, рассмотренным ниже). Родной Приложение, Что OAuth2 Лучшие Практики Какой бы подход вы выберете (есть несколько компромиссов, чтобы рассмотреть), вы должны обратить внимание на лучшие практики, описанные здесь для "родных" приложений с использованием OAuth2: https://tools.ietf.org/html/rfc8252 Рассмотрите следующие варианты Неявные Я должен использовать неявную? Цитата из п. 8.2. https://tools.ietf.org/html/rfc8252#section-8.2

OAuth 2.0 или подразумеваемого предоставления авторизации потока (определенного в п. 4.2 протокола OAuth 2.0 [RFC6749]) вообще работает с практикой выполнения запроса на авторизацию в браузере и получив ответ авторизации через Ури на основе обмена данными между приложениями. однако, как неявный поток не может быть защищено путем Эпсилон [RFC7636] (которая требуется в разделе 8.1), использование неявного потока с родных приложений не рекомендуется. маркеры доступа, предоставляемые через неявный поток также не может быть обновлен без взаимодействия с пользователем, делая грант кода авторизации -- которые могут выдавать жетоны обновить-более практичный вариант для родного приложения разрешений, которые требуют обновления маркера доступа. Код Авторизации Если вы идете с кодом авторизации, затем один подход будет прокси через свой собственный компонент веб-сервер, который обогащает запросов с клиента в секрете, чтобы избежать сохранения на распределенные приложения на устройствах. Ниже отрывок из: https://dev.fitbit.com/docs/oauth2/ Грант кода авторизации рекомендуется для приложений, которые есть веб-сервис. Этот поток требует межсерверную связь с помощью приложения's не секрет клиента.

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

применения, которые не имеют веб-сервиса должен использовать неявную даруй поток. Вывод Окончательное решение должна учитывать необходимый опыт пользователя, но и на аппетит к риску после проведения оценки рисков ваших шорт подходов и лучшего понимания последствий. Многие читают здесь https://auth0.com/blog/oauth-2-best-practices-for-native-apps/ Еще один https://www.oauth.com/oauth2-servers/oauth-native-apps/ которых государства В текущей отрасли рекомендуется использовать поток авторизации В то время, как клиенту тайну, и на использование внешнего пользователя агента полная потоком. Внешнего агента пользователя, как правило, устройства В родном браузере, (с отдельной безопасности домена от родного приложения) так что приложение не может получить доступ к хранилищу файлов cookie или проверить или изменить содержание страницы в браузере. Рассмотрение Эпсилон Вы должны также рассмотреть Эпсилон, который описан здесь https://www.oauth.com/oauth2-servers/pkce/ В частности, если Вы являются также осуществляет авторизационный сервер тогда https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ говорится, что вы должны

  • Позволяет клиентам зарегистрировать пользовательские схемы URL-адрес для перенаправления URL-адреса.
  • Поддержка петлевой IP перенаправление URL-адреса с произвольным числом портов в целях поддержки настольных приложений.
  • Не думайте, родные приложения могут хранить секреты. Требовать, чтобы все приложения, чтобы объявить, являются ли они государственными или конфиденциальным, и вопрос только секреты клиента для конфиденциальных приложений.
  • Поддержка расширения Эпсилон, и требуют, чтобы государственные клиенты используют его.
  • Попытка определить, когда интерфейс авторизации, встроенных в web-приложение-это вид, а не запущенных в браузере системы, и отвергать эти просьбы. Веб-Видом Рассмотрение Есть много примеров в дикой природе, используя веб-представлений, т. е. внедренного агента пользователя, но такой подход следует избегать (особенно, когда приложение не первая партия) и в некоторых случаях может привести к увольнению с использованием API, а ниже отрывок из здесь показано, любая попытка добавьте страницу проверки подлинности OAuth 2.0 приведет к По вашей заявке запретили производитель API-интерфейс.

для рассмотрения безопасности, страница авторизации OAuth 2.0 должен быть представлены в специальном представлении браузера. Компания Fitbit пользователи могут только подтвердить их идентификация с подлинными сайте Fitbit.com если они есть средства, предоставляемые браузером, таких как бар URL и транспорта безопасность слоя (TLS) и данные сертификата.

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

приложения iOS могут использовать класс SFSafariViewController вместо переключение приложений в Safari. Использование WKWebView или класса UIWebView является запрещается.

Андроид приложения могут использовать Chrome пользовательских вкладок вместо приложения переход в браузере по умолчанию. Использование WebView это запрещено. Для большей ясности приведу цитату из Этот раздел из предыдущего проекта наилучшую практику ссылке выше встроенный пользовательскими агентами, обычно реализуется с веб-видом, являются альтернативный метод для авторизации приложения. Однако они небезопасным для использования третьими сторонами по определению. Они включают пользователя вход с их полной учетные данные для входа, только у них downscoped на менее мощные учетные данные OAuth.

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

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

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

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

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

авторизации сервера должны рассмотреть вопрос о принятии мер для обнаружения и блокирования входы через встроенные пользователей-агентов, которые не свои, где возможно. Некоторые интересные места также вырос здесь: https://security.stackexchange.com/questions/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the-a

Matt C
Редактировал ответ 29-го августа 2018 в 11:38
Комментарии (3)

К сожалению, я не'т думаю, что есть четкий ответ на этот вопрос. Однако, тут есть варианты, которые я'вэ определены:

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

  • Удобство использования или политики безопасности запрещают включение пароль непосредственно в приложение

  • Процесс проверки подлинности возложена на внешнего поставщика удостоверений и должно выполняться посредством перенаправления HTTP на основе потока (например, OpenID, SAMLP или WS-Федерации)

  • При использовании браузера на основе расхода, а затем использовать потока кода авторизации. Здесь определение параметр redirect_uri является серьезной проблемой, для которой есть следующие варианты:

  • Используйте метод, описанный в https://developers.google.com/accounts/docs/OAuth2InstalledApp, где-это параметр redirect_uri(например,урна теме:IETF:РГ:протокол OAuth:2.0:ооб`) сигналы конечную точку авторизации, чтобы показать код авторизации вместо перенаправления обратно в клиентское приложение. Пользователь может вручную скопируйте этот код или приложение, можете попробовать получить его из заголовка HTML-документа.

  • Использовать локальным localhost сервера на устройства (руководство порта не может быть легким).

  • Использовать пользовательские схемы URI (например, приложение myapp://...), что когда разыменовывается вызывает зарегистрированы на "проводник" и (подробности зависят от мобильной платформы).

  • Если есть возможность, используйте специальные и"веб-представление" и, например, WebAuthenticationBroker на Windows 8, для контроля и доступа к HTTP-перенаправление ответов.

Надеюсь, что это помогает

Педро

Комментарии (9)

ТЛ;ДР: используйте предоставления кода авторизации с Эпсилон

1. Неявный Тип Гранта

Неявный тип гранта является довольно популярным среди мобильных приложений. Но она не должна использоваться, как это. Есть соображения безопасности вокруг редирект. Джастин богаче государства:

проблема приходит, когда вы понимаете, что в отличие от удаленного сервера URL-адрес не существует надежного способа, чтобы гарантировать, что привязки между с учетом URI перенаправления и специального мобильного приложения заслуженный. Любой приложение на устройство можно попробовать вставить себе в перенаправление процесс и заставить его служить URI перенаправления. И думаю, что: если вы использовали неявный поток в собственном приложении, то вы просто передал злоумышленнику свой маркер доступа. Нет спасения от ссылки — у них есть маркер и могут их использовать.

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

2. Тип Авторизации Предоставить Код

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

мы рекомендуем, что маркеры доступа приложение должно использоваться только непосредственно с и GT; приложения'ы серверов для того, чтобы обеспечить максимальную безопасность. Для родной приложения, мы рекомендуем, что приложение взаимодействует со своим сервером и тогда сервер делает запросы к API для Facebook, используя приложение маркер доступа.

Не идеальное решение, но есть новый, лучший путь, чтобы сделать с OAuth на мобильных устройствах: основные доказательства для обмена код

3. Предоставления кода авторизации тип с-Эпсилон (ключевые доказательство для обмена кодом)

Из ограничений, новая методика была создана, которые позволяют использовать код авторизации без секрета клиента. Вы можете прочитать полный РЧЦ 7636 или это краткое введение.

Эпсилон (РЧЦ 7636) - это метод для обеспечения государственных клиентов, что Дон'т использовать секрет клиента.

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

от https://oauth.net/2/pkce/

Johannes Filter
Редактировал ответ 6-го марта 2018 в 2:27
Комментарии (0)

Используя WebView в вашем мобильном приложении должен быть доступный способ реализовать что OAuth2.0 протокол на платформе Android.

Как для параметр redirect_uri поле, я думаю, http://localhost это хороший выбор, и вы Дон'т придется порт HTTP-сервер внутри вашего приложения, потому что вы можете переопределить реализацию onPageStarted функции WebViewClient класса и остановить загрузку веб-страницы с http://localhost после проверкиURL-адрес` параметр.

public void onPageStarted(final WebView webView, final String url,
        final Bitmap favicon) {}
Комментарии (3)

Самый удобный для пользователя для проверки подлинности, и простым в реализации будет вставить WebView в приложение. Обработать ответы, полученные в WebView с точки аутентификации и выявления ошибок (отмена пользователем) или утверждения (и извлекать токен из параметров URL-запроса). И я думаю, что вы можете сделать это на всех платформах. Я успешно сделал это для: iOS, андроид, Мак, магазина Windows 8.1-приложения, приложения Windows 8.1. Я сделал это для следующие услуги: Dropbox, Google Диск, OneDrive, коробка, бейскемп. Для платформ, отличных от Windows, я был с использованием Xamarin, которые якобы не подвергайте всю конкретных API платформы, в то же время он достаточно выставить на этом. Так что это довольно доступное решение, даже с креста перспективной платформы, и вы Дон'т придется беспокоиться о пользовательском интерфейсе формы проверки подлинности.

Комментарии (6)