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

Ответ 1

Пояснение: мобильное приложение = родное приложение

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

Собственное приложение OAuth2 Best Practices

Какой бы подход вы ни выбрали (есть несколько компромиссов, на которые следует обратить внимание), вы должны обратить внимание на лучшие практики, изложенные здесь для собственных приложений, использующих 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]) обычно работает с практикой выполнения запроса авторизации в браузере и получения ответа на авторизацию посредством связи между приложениями на основе URI.
Однако, поскольку неявный поток не может быть защищен PKCE [RFC7636] (что требуется в разделе 8.1), использование неявного потока с собственными приложениями НЕ РЕКОМЕНДУЕТСЯ.

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

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

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

Выдержка из: https://dev.fitbit.com/docs/oauth2/

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

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

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

Заключение

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

Отличное чтение здесь https://auth0.com/blog/oauth-2-best-practices-for-native-apps/

Еще один https://www.oauth.com/oauth2-servers/oauth-native-apps/, который гласит

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

Рассмотрение PKCE

Вы также должны рассмотреть PKCE, который описан здесь https://www.oauth.com/oauth2-servers/pkce/

В частности, если вы также внедряете Сервер авторизации, то https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ заявляет, что вам следует

• Разрешить клиентам регистрировать собственные схемы URL для своих URL перенаправления.
• Поддержка петлевых IP-адресов перенаправления с произвольными номерами портов для поддержки настольных приложений.
• Не думайте, что нативные приложения могут держать в секрете. Требовать от всех приложений указывать, являются ли они общедоступными или конфиденциальными, и передавать секретные приложения только конфиденциальным приложениям.
• Поддержите расширение PKCE и потребуйте, чтобы его использовали общедоступные клиенты.
• Попытайтесь определить, встроен ли интерфейс авторизации в веб-представление собственных приложений, а не запущен в системном браузере, и отклонить эти запросы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Серверы авторизации ДОЛЖНЫ рассмотреть возможность принятия мер для обнаружения и блокировки вход через встроенных user- агентов, которые не являются их собственными, где возможно.

Здесь также поднимаются некоторые интересные моменты: https://security.stackexchange.com/questions/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the-a

Ответ 2

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

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

  • Правила использования или безопасности запрещают вставку пароля непосредственно в приложение
  • Процесс аутентификации делегируется внешнему поставщику идентификаторов и должен выполняться через потоки с перенаправлением 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.

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

Педро

Ответ 3

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

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

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

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

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

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

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

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

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

3. Тип предоставления кода авторизации с PKCE (проверочный ключ для обмена кодами)

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

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

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

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

Ответ 4

Использование 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) {}

Ответ 5

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