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

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

4b9b3361

Уточнение: Mobile 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

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

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

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

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

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

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

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

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

Заключение

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

Рассмотрение веб-просмотров

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

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

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

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

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

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

Чтобы уточнить, вот цитата из этого раздела предыдущего проекта ссылки на лучшую практику, представленную выше

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

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

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

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

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

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

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

30
ответ дан 26 июля '16 в 9:37
источник

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

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

    • Правила использования или безопасности запрещают вставку пароля непосредственно в приложение
    • Процесс аутентификации делегируется внешнему поставщику идентификаторов и должен выполняться через потоки с перенаправлением HTTP (например, OpenID, SAMLP или WS-Federation).
  • Если требуется использование потока на основе браузера, используйте поток кода авторизации. Здесь определение 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.

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

Педро

18
ответ дан 02 июля '13 в 17:41
источник

Использование 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) {}
-2
ответ дан 20 февр. '15 в 21:58
источник

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

-4
ответ дан 18 февр. '15 в 0:55
источник