Конфигурация единого клиента OAuth 2.0 для веб- и мобильных приложений
В настоящее время я работаю над интеграцией OAuth 2.0 в веб-приложение, которое позволяет пользователям проходить аутентификацию с использованием своих учетных записей Google. Аутентификация осуществляется непосредственно во внешнем интерфейсе нашего веб-приложения с использованием OAuth 2.0. Эта настройка отлично работает при доступе через веб-браузер.
Однако возникают проблемы, когда к этому же приложению осуществляется доступ через веб-представления в наших мобильных приложениях для Android и iOS. Попытка войти в систему с помощью Google из мобильных приложений не удалась, предположительно потому, что поток Google OAuth не оптимизирован для обработки аутентификации в мобильных веб-представлениях.
Предлагаемый подход к решению этой проблемы предполагает настройку отдельных клиентов OAuth 2.0 для Android и iOS в дополнение к существующему веб-клиенту. Однако управление несколькими клиентами OAuth для одного и того же приложения кажется неэффективным и потенциально увеличивает сложность нашей системы.
Я обдумываю решение, при котором все запросы аутентификации, независимо от клиента (веб- или мобильного), направляются через сервер. Идея состоит в том, что и веб-интерфейс, и мобильные приложения будут взаимодействовать с нашим сервером, который затем будет обрабатывать аутентификацию OAuth в Google от их имени. Этот подход потенциально может позволить нам поддерживать единую конфигурацию клиента OAuth.
Мой вопрос: позволит ли эта установка эффективно обойти необходимость в нескольких клиентах OAuth для разных платформ?
Любые идеи или советы по этому поводу будут очень признательны.
Спасибо
Ответы 2
ВЕБ-КЛИЕНТЫ
Самое простое решение на мобильном устройстве — вызвать веб-приложение в системном браузере, а не использовать веб-просмотр:
В наши дни веб-просмотр проблематичен для защищенных приложений, поскольку они используют приватный сеанс браузера. Например, они не могут использовать файлы cookie или автозаполнение в основном браузере. Маршрутизация запросов через сервер не поможет, если в веб-просмотре по-прежнему происходит перенаправление по переднему каналу.
Google и Apple предпочитают, чтобы вы предоставляли браузер для веб-приложений на мобильных устройствах и экономно использовали веб-просмотры.
МОБИЛЬНЫЕ КЛИЕНТЫ
Оптимальным решением в долгосрочной перспективе является повторная реализация веб-представлений как собственных представлений. Тогда ваше мобильное приложение будет отдельным клиентом OAuth, который реализует свой поток в соответствии с RFC 8252 и использует другую форму URI перенаправления.
Регистрировать разные клиенты OAuth для веб-платформ и мобильных платформ вполне нормально. Это не влечет за собой больших накладных расходов. Обе платформы имеют разные передовые практики. Решения обычно включают в себя приложения, вызывающие одни и те же API-интерфейсы, защищенные OAuth.
Однако поддерживать обе платформы и обеспечивать удобство взаимодействия с пользователем непросто, поскольку это требует некоторой фундаментальной работы.
Как отметил @Gary Archer, использование Google для входа в систему непосредственно из веб-просмотра запрещено Google, поскольку они утверждают, что текущий браузер небезопасен или что-то в этом роде. Однако преобразовать содержимое веб-просмотра в приложение для телефона было невозможно, поэтому мне пришлось искать обходной путь. В итоге я инициировал процесс входа в Google в веб-просмотре, но открыл всплывающее окно входа в Google в родном браузере. После того, как пользователь вводит свои учетные данные, он перенаправляется на частный сайт, где код клиента Google извлекается из параметров URL-адреса и отправляется в телефонное приложение с использованием универсальной ссылки. Затем телефонное приложение получает код, вводит его в веб-просмотр, где он обменивается, успешно регистрируя пользователя. Это работает для всех трех платформ (веб, iOS, Android) только с одним клиентом OAuth, что является долгожданным решением.