'Navigation is blocked' when warming up Chrome Custom Tabs given active session with Authorization Service

[FreeWillaert]

This is the scenario:
Configure the AppAuth example as usual (client_id, redirect_uri, authorization_scope and discovery_uri, appAuthRedirectScheme). Run the app, login with some user so that Chrome has a session with the Authorization Server, then hit "Sign out" (which only removes the app's state, not the browser session).

Then:

1. Hit "Start Authorization". => Browser tab opens, but the redirect back to the app fails and the browser tab stays open. The log shows the infamous "Navigation is blocked" error from chromium.
2. Close the browser tab manually.
3. Hit "Start Authorization" again. => This time, the browser tab shows briefly, and then the redirect succeeds, authorization code comes back to the app and is exchanged for a token.
4. Hit "Signout" again. Now go back to 1. and repeat - the result is the same each time.

After a lot of digging, I found that when the app starts and/or user hits Signout, the browser tab is already prewarmed with an actual auth request, and when the user subsequently hits "Start Authorization", Chrome does NOT pass the actual auth request to the Authorization Service - but instead it tries to return immediately followed by "Navigation is blocked".

Eventually, it appears that the "Navigation is blocked" error can be avoided by either:
a) Not warming up the browser tab.
b) Warming up the browser tab but with an empty query string (no client_id,...).
c) Warming up the browser tab but add e.g. a "warmup=true" part to the query string.

FYI, option c is done by changing the following line in LoginActivity.warmUpBrowser:

        Uri realAuthUri = mAuthRequest.get().toUri();
        Uri dummyAuthUri = realAuthUri.buildUpon().appendQueryParameter("warmup","true").build();
        CustomTabsIntent.Builder intentBuilder =
            mAuthService.createCustomTabsIntentBuilder(dummyAuthUri); 

Any of these actions ensures that an actual authorization request is made to the Authorization Service, and no more "Navigation is blocked".

=> Is this behavior to be expected? Is there anything the Authorization Service should do to avoid it?
=> What is the recommended approach: a, b or c ? or perhaps something else still?

[iainmcgin]

I'm speculating a little here, but I think the core issue is that the IDP is automatically redirecting back to the app in response to the authorization request because the user is already signed in - does that sound right? If the IDP displays a page that requires user action, such as pressing a button, before completing the authorization flow I expect that things will work as expected.

Tweaking the request parameters is an interesting work-around, as a way of performing a partial warm-up of the request. As OAuth2 is defined such that unknown parameters should be ignored, it should be safe to add a dummy parameter as you suggest, and benefit from pre-fetch of some page resources like images, but it won't be a full warm-up, as changing the request parameters will require a fetch of the main page again.

Option (a) is safe, it might just be slower.

Option (b) would in most cases be worse than (a), as the page you "warm up" will likely be an error page due to missing or invalid request parameters. Resources from this error page probably won't be reusable in the rendering of the real request, so time and data transfer was just wasted.

Option (c) may be problematic, as the IDP may end up issuing two authorization codes per request, if it is automatically redirecting in response to the authorization request. That's worth checking; if it's not doing that, then this option is safe.

[thomaux]

Hi @iainmcgin, I work with @FreeWillaert on the same project where we're experiencing this issue. Thank you for your response. Allow me to comment on your assumption and hopefully shed some more light on the matter.

The authorization flow where the user is immediately redirected back to the app does work (but not consistently, due to the prewarming error).

What happens in that scenario is that the user will hit the auth endpoint on the IDP and will be immediately redirected back to the provided redirect URI with the tokens. From the borwser's perspective (and my opinion) this should be fine as the user navigates to a server and is then consecutively redirected back through a 302 (instead of a JavaScript redirect).

Our previous workaround was indeed to include a page with a button to go back to the app, causing the redirect to be an explicit user action.

[ratkins]

We're seeing this behavior too. What does c) look like if we're relying on AppAuth to automatically select a browser for us? adding authBuilder.setAdditionalParameters(singletonMap("warmup", "true")) doesn't seem to help.

(Also, has option c) been found to be safe? We're using Keycloak as our IDP.)

[Jeyahariprakash]

@FreeWillaert : Your hack didn't help me. I am also facing the similar issue.

Issue what I am facing :

1. Login into android mobile app with AppAuth framework. (Custom tab able to redirect the uri and close the custom tab properly)
2. Logout the mobile app
3. Login again
4. Now after successful login, custom tab not closing itself / not Navigating back to application .

Debug analysis :
After dig into this issue, I found out that chrome custom tab is "Blocking the navigation" (which prints at console message)

Tried work around:

1. Appended query param "warmup" with true
2. Added "FLAG_ACTIVITY_NO_HISTORY" & "FLAG_ACTIVITY_NEW_TASK" to custom intent
3. Cleared custom tab cookies manually from settings. Nothing worked out.

Any suggestions for me?

[Cooke]

Maybe this issue will be solved in version 72 in chrome. It seems to be for some: https://crbug.com/738724