Какой правильный поток OAuth 2.0 для мобильного приложения

Question

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

Answer 1

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

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

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

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

  • Используйте метод, описанный в https://developers.google.com/accounts/docs/OAuth2InstalledApp, где специальный redirect_uri (например urn:ietf:wg:oauth:2.0:oob) сигнализирует конечную точку авторизации, чтобы показать код авторизации вместо перенаправления обратно в клиентское приложение. Пользователь может вручную скопировать этот код, или приложение может попытаться получить его из заголовка документа HTML.
  • Используйте сервер localhost на устройстве (управление портами может быть нелегким).
  • Используйте настраиваемую схему URI (например, myapp://...), которая при разыменовании запускает зарегистрированный «обработчик» (детали зависят от мобильной платформы).
  • Если доступно, используйте специальный «веб-просмотр», такой как WebAuthenticationBroker в Windows 8, для управления и доступа к ответам перенаправления HTTP.

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

Педро

Answer 2

The плавного опыт пользователю для аутентификации, и легче всего реализовать, чтобы внедрить WebView в приложении. Обработать ответы, полученные веб-просмотром, с точки аутентификации и обнаружить ошибку (отмена пользователя) или одобрение (и извлечь токен из параметров запроса url). И я думаю, вы действительно можете это сделать на всех платформах. Я успешно выполнил эту работу по следующим темам: ios, android, mac, Windows store 8.1 приложения, приложение Windows Phone 8.1. Я сделал это для следующих сервисов: dropbox, google drive, onedrive, box, basecamp.Для платформ, отличных от Windows, я использовал Xamarin, который, предположительно, не раскрывает все API-интерфейсы, специфичные для платформы, но он достаточно разоблачил, чтобы сделать это возможным. Таким образом, это довольно доступное решение, даже с точки зрения перекрестной платформы, и вам не нужно беспокоиться о ui формы аутентификации.

Answer 3

Использование веб-просмотра в мобильном приложении должно быть доступным способом реализации протокола 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) {} 

Answer 4

Разъяснение: Mobile App = Native App

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

Native App OAuth2 Best Practices

Какой бы подход вы выбираете (есть несколько компромиссов, чтобы рассмотреть), следует обратить внимание на лучшие практики, как описано здесь Native Apps с помощью oauth2: https://tools.ietf.org/html/draft-ietf-oauth-native-apps

Неявный

Должен ли я использовать неявный?

Цитирую https://tools.ietf.org/html/draft-ietf-oauth-native-apps-06#section-8.5

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

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

Код авторизации

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

Отрывок ниже от: https://dev.fitbit.com/docs/oauth2/

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

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

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

Заключение

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

Web просмотры Рассмотрение

Есть много примеров в дикой природе, используя веб-просмотры, то есть встроенный агент пользователя, но этот подход следует избегать (особенно, когда приложение не является первой стороны), а в некоторых случаях может привести к вам запретили с использованием API как ниже отрывок из here демонстрирует

Любая попытка встроить страницу аутентификации OAuth 2.0 приведет к приложение запретили из API FitBit.

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

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

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

Приложения для Android могут использовать пользовательские вкладки Chrome вместо приложения , переключение на браузер по умолчанию. Использование WebView запрещено.

Для дальнейшего уточнения, вот цитата из this section предыдущего проекта по ссылке наилучшей практики, представленного выше

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

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

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

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

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

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

Серверы авторизации СЛЕДУЕТ рассмотреть возможность принятия и регистрации логинов через встроенные пользовательские агенты, которые не являются их собственными, где возможно использование .

Answer 5

TL; DR: Использование кода авторизации Грант с PKCE

1. неявного типа Грант

неявной типа гранта является довольно популярным с мобильными приложениями. Но это не предназначалось для такого использования. Вокруг перенаправления есть проблемы с безопасностью. Justin Richer states:

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

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

2.Код авторизации Тип гранта

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

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

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

3. Авторизация Код типа Grant с PKCE (Proof Key для Кодекса Биржа)

Из-за ограничений была создана новая техника, позволяющая использовать код авторизации без секретности клиента. Вы можете прочитать полный текст RFC 7636 или this short introduction.

PKCE (RFC 7636) - это метод, позволяющий публичным клиентам не использовать секрет клиента.

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

из https://oauth.net/2/pkce/