"Навигация заблокирована" при перенаправлении из пользовательской вкладки Chrome в приложение Android

Question

Я "модернизирую" наш виджет входа в систему, чтобы использовать пользовательские вкладки Chrome, поскольку Google начнет блокировать запросы OAuth с помощью веб-просмотров через несколько месяцев.

Виджет входа в систему работает с нашей службой идентификации, которая поддерживает классический вход в систему "имя пользователя и пароль" и социальный вход в систему, играя OAuth2 "Клиент" в потоке кода авторизации с Google/Facebook/... Таким образом, код авторизации от Google доставляется на этот адрес Identity Service, которая, в свою очередь, предоставляет нашему виджету входа в систему токен доступа.

Маркер доступа передается обратно в мобильное приложение через перенаправление на стороне клиента:

window.location.replace('com.acmeusercontent.tenants.abc:\/setTokenData?accessToken='+access_token+'#');

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

Однако для входа в социальную сеть при перенаправлении ничего не происходит, кроме этой строки в Android Monitor:

I/chromium: [INFO:CONSOLE(0)] "Navigation is blocked: com.acmeusercontent.tenants.abc:/setTokenData..."

Просто для ясности: как для классического, так и для социального входа перенаправление на стороне клиента точно такое же, но после классического входа в систему оно разрешено, а после входа в систему оно заблокировано! И, если я добавлю в виджет кнопку, которая делает то же самое перенаправление после входа в систему, она снова будет разрешена - до тех пор, пока пользователь нажимает на нее.

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

Я перепробовал все, что мог придумать: используя синтаксис "intent:", имитируя нажатие кнопки в коде, используя перенаправление на стороне сервера,... но ничего не работает. Кроме того, я изучил библиотеки AppAuth на примере аутентификации Google, и, насколько я могу судить, я делаю то же самое.

Answer 1

Я ведущий сопровождающий AppAuth.

Политика на стороне Chrome для запуска перенаправлений в приложение, будь то через пользовательскую схему или https App Link, заключается в том, что это действие должно запускаться пользователем, а не Javascript. Я полагаю, что цель здесь состоит в том, чтобы предотвратить удивление пользователей, когда сайт открывает приложение без их явного "согласия" в виде нажатия на ссылку.

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

Я поддерживаю демонстрацию, которая показывает, как перехватить перенаправление OAuth и перенаправить его в приложение после того, как пользователь нажмет здесь:

https://github.com/iainmcgin/AppAuth-Demo

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