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

Question

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

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

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

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

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

Answer 1

СЦЕНАРИЙ

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

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

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

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

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

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

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

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

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

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

Я подозреваю, что Ответственное и оправданное использование WKWebView будет приемлемым. Я могу ошибаться, поэтому, пожалуйста, не верьте мне на слово.

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

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