OpenID Connect: передача авторизации между мобильным приложением и браузером для единого входа — как это сделать безопасно?

Я не уверен, что существует «правильный» способ, но прежде чем я просто соберу свою собственную несовместимую реализацию, возможно, во всех стандартах есть что-то, что может удовлетворить мои потребности?

Вот ситуация: Apple заявила, что приложения на их телефонах ДОЛЖНЫ включать в себя все стандартные функции внутри себя. Больше никаких фреймов с веб-контентом! Если вам нужно показать материал из Интернета, откройте системный браузер (Safari)! К сожалению, нам нужно отображать материалы из Интернета, так что поехали...

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

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

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


person Vilx-    schedule 16.06.2020    source источник


Ответы (1)


СЦЕНАРИЙ

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

ИНТЕГРИРОВАННОЕ РЕШЕНИЕ ДЛЯ ВЕБ И МОБИЛЬНЫХ УСТРОЙСТВ ЧЕРЕЗ ОТКЛЮЧЕННЫЙ БРАУЗЕР?

В идеале вы хотите передать JWT мобильного приложения внешнему веб-контенту в заголовке HTTP. Однако API-интерфейсы iOS, такие как openURL, могут не поддерживать это.

Возможно, вам придется передать JWT в строке запроса, и в этом случае я бы попытался следовать модель подписанного запроса, хотя это и не тривиально. Я использовал подписанные запросы SalesForce, хотя сам не реализовал полное решение.

  • Мобильное приложение вызывает метод API в POST /api/encrypt-token
  • API возвращает зашифрованную полезную нагрузку, включающую JWT.
  • Мобильное приложение открывает веб-страницу по адресу https://mywebapp?token=0a78904cwdu.
  • Веб-интерфейс вызывает POST /api/decrypt-token для получения JWT.
  • Веб-интерфейс сохраняет токен в памяти и использует его для вызова API.

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

ИНТЕГРИРОВАННОЕ РЕШЕНИЕ ДЛЯ ВЕБ И МОБИЛЬНЫХ УСТРОЙСТВ ЧЕРЕЗ WKWEBVIEW

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

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

ДЕЙСТВИТЕЛЬНОЕ ИСПОЛЬЗОВАНИЕ ВЕБ-ПРОСМОТРЕЙ?

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

  • Использование UIWebView — значение по умолчанию для Cordova — необходимо обновить до WKWebView.
  • Предоставление приложения, которое представляет собой исключительно переупакованный веб-сайт без мобильных просмотров.
  • Отображение веб-контента сомнительного характера (реклама и т. д.)

Я подозреваю, что ответственное и обоснованное использование WKWebView будет принято. Хотя я могу ошибаться, так что не верьте мне на слово.

ОНЛАЙН-ОБРАЗЦЫ

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

person Gary Archer    schedule 16.06.2020
comment
В этом-то и дело. Если бы наши ребята могли использовать WebView, проблем бы не было. Но, насколько я понимаю, обновленные условия включают что-то вроде всех основных функций, которые должны быть в пакете приложения и не могут быть загружены во время выполнения. Для отображения внешних веб-страниц запустите Safari. Я не знаю подробностей, так как я работаю не над приложением, а над бэкэндом. Предположительно, это было довольно расплывчато определено, и они долго ломали голову, пока не решили, что лучше перестраховаться, чем сожалеть, и отказались от веб-просмотров. Завтра постараюсь получить ссылку. - person Vilx-; 16.06.2020
comment
Чтобы уточнить: само приложение написано на HTML/JS, так что на самом деле оно является одним большим WebView (я думаю, что оно использует Apache Cordova для работы как на Android, так и на iOS). Но нельзя открывать iframe с внешним веб-сайтом. Он может показывать только локальные ресурсы. - person Vilx-; 16.06.2020
comment
Теперь я вижу твою озабоченность. Cordova HTML/JS подходит, поскольку он транслируется в собственные представления в процессе компиляции. Внешний веб-контент может быть в порядке в элементах управления WKWebView, хотя это может зависеть от того, какой процент вашего приложения он составляет. Я добавил несколько примечаний к своему исходному ответу выше. - person Gary Archer; 17.06.2020
comment
Это не будет большим процентом, но это, безусловно, будет частью его основной функциональности и будет включать финансовые транзакции. И да, они недавно закончили перемещать материал в WKWebView, если мне не изменяет память. Я не знаю, захочет ли Apple оставить это без внимания, но мы также не хотим рисковать. Так что это внешний браузер. - person Vilx-; 17.06.2020
comment
Причина, по которой мы не хотим портировать новую функциональность в само приложение, в основном из-за проблем со стоимостью/временем. В любом случае, это уже должно быть частью нашей веб-страницы, поэтому более эффективно просто сделать веб-страницу отзывчивой и указать на нее приложению, а не повторно реализовывать сложный код в приложении. Также он находится в активной разработке, поэтому ожидаются изменения. Возможно, когда-нибудь мы переместим его в само приложение, но сейчас нам нужно более быстрое решение. - person Vilx-; 17.06.2020
comment
Круто - похоже, что передача мобильного JWT внешнему веб-контенту - это путь, но это сложная вещь, о которой вы просите. Я бы рассмотрел шаблон «подписанный запрос», как в моем обновленном ответе. Это используется довольно многими технологическими стеками поставщиков, такими как AWS / SalesForce ... - person Gary Archer; 17.06.2020
comment
Это также модель, с которой я пытаюсь работать. Это лучшее, что я могу придумать, но у него есть один недостаток: одноразовый код, который я передаю веб-сайту в URL-адресе, — это все, что необходимо для окончательной аутентификации. OAuth был очень осторожен, чтобы избежать такой ситуации в своих потоках, полагаясь дополнительно либо на аутентификацию клиента, либо на PKCE. Я думаю, это не имеет большого значения, и в целом это довольно сложная вещь для использования, но... это не совсем правильно. :) - person Vilx-; 17.06.2020