Android Intent not broadcast on slow authentications - Questions

[sjorsdehaas]

Configuration

• Version: 0.9.1
• Integration: Kotlin / Android
• Identity provider: Signicat / NemID / MitID / BankId (mobil)

Description

We are developing an app for Denmark and Norway for our client, that in order use you need to authenticate with a national identity provider. This is setup through a 3rd party - Signicat.

This authentication is done with a custom tabs browser launched from the app. The user can authenticate through a different app installed on either the same or a different device. After successful authentication, the user should receive a redirect with the authCode that triggers the sending of an Intent. This intent launches a chooser for all apps whose packages match. This happy flow works totally fine.

The client's testers have noticed that if this authentication happens too slow, give or take 10 seconds or longer, the chooser will no longer show. Sometimes the custom tabs will appear to load, but never as far as in the happy flow, sometimes the loading bar will not even show. The Intent is never broadcast on the system according to the logs. This issue seems to be Android specific, iOS is not affected according to the testers.

I have come across this (https://stackoverflow.com/a/41882732) answer on a seemingly similar issue and was wondering if this is still relevant. I have floated the suggestion of implementing a user action to trigger the redirect, but there is some reluctance as this would affect their regular online portals as well.

We have a discussion around this subject planned for next week and I would like to get the situation (for the app's perspective) as clear as I can.

Is the issue mentioned in the SO post still relevant? Is this related to the issues that we are experiencing?

If there is any other configuration / technical information I can provide, don't hesitate to ask :)

Thanks in advance,

[agologan]

The reference SO response by Iain is still correct.

It's not very clear from what you've describe what the actual user workflow is. It might be you already have the user interaction "chain" described by Iain already in your app.

What sticks out at me from your description is the app chooser, which is also referred to as a disambiguation dialog. This is usually presented when the "link" between apps is vague enough the OS doesn't know where to redirect to. Depending on the Android version this is only presented once and the response saved. In very few cases having it there might end up breaking the workflow on subsequent attempts. This usually points to a misconfiguration on the app developers end, unless it's all intentional (like an app showing a share sheet).

[sjorsdehaas]

Thank you for your response.

For reference, this is a single activity app with using fragments for views (almost all full screen) Some more clarification on the actual user flow:

• A new user is presented with our activation fragment to activate the app on start up
• Clicking the button 'activate the app' launches a TokenRetrievalFragment, which initializes the AuthorizationService and launches the AuthorizationRequestIntent using registerActivityForResult(ActivityResultContracts.StartActivityForResult()). If the result is received (which it isn't in my situation), we use the response to exchange the authorization code for a set of tokens. Only if this succeeds do we consider the user activated
• After launching the Intent, a CustomTabs browser opens where the user goes through the following choices:
  • Language
  • Identity provider (NemID/MitID for Denmark, BankId/BankID for mobile in Norway)
  • In some options an additional choice whether to authenticate on this device or a different one
• After this the browser indicates the user to authenticate and is waiting for the redirect back to the app. This is where the behaviour from my initial post shows up.

Whilst writing this response, your reply did trigger me to do some more investigating/testing. Specifically that the link (redirectUri) is disambiguous. I do believe that you picked up on the issue at hand.

We have several different buildTypes for the app (debug/uat/preprod/release), which can be installed separately from each other on the same device, because of the 'applicationIdSuffix ".dev/.uat/.preprod"' in their buildType configuration. However, they do all use the same redirectUri in the AuthorizationRequest, and register the RedirectUriReceiverActivity using the manifestPlacholders =["appAuthRedirectScheme": ] because those are based on the productFlavor (denmark or norway). That is the crux of this issue if I'm not mistaken.

Having first reproduced the issue with both .dev and .uat installed - I had not opened .dev or tried authentication, just reproduced the issue with .uat - I can confirm that this behaviour changes if there is only one version of the app installed. When only one version of the app is installed, the browser will show a prompt rather than a disambiguation dialog asking to open the correct app regardless of how long the user takes to authenticate (before any timeouts of course). Subsequent activations/authentications open the app without any prompt.

Reinstalling .dev - but not attempting authentication - reintroduces the problem of nothing happening after a slow authentication. A quick authentication will show the disambiguation dialog listing the two installed versions.

The fact that nothing happens after a slow authentication could be due to inactivity of the user and therefore link to the SO answer from Lain. However, seeing as this situation would not happen for any users outside of our testers and developers, I do not think it is will be a priority for us to fix. If we do, we will make the redirect uri/scheme dependant on both the buildType and productFlavor to avoid any ambiguity.

Could you confirm or correct the above? Both for the meeting I'm preparing for and for any others that experience this behaviour in the future?

Thanks for you support in the matter

[agologan]

Your description sounds reasonable. Recommend you use distinct redirectUris for each flavor and separate clients registered with your IdP for at least dev vs prod.