SSO Login with Google is Unsupported

[jkuester]

Describe the bug
#396 added general support for SSO login in cht-android by allowing URLs containing the proper redirect_uri query param to be opened in the root webview for the app.

Unfortunately, this does not work when using Google as the OIDC Provider (or as a proxied authentication server as is the case when Microsoft Entra is configured to allow guest login via Google accounts). Google refuses to allow authentication for its accounts in Android WebView at all. (Citing security concerns...)

To Reproduce
Steps to reproduce the behavior:

1. Configure Google as your OIDC provider on your CHT instance:
2. In your cht-android app, select the "Login with SSO" button from the login screen
3. See the error page:

Note that if you are using Google as a proxied authentication server (behind a different OIDC Provider), you might experience different behavior. When using Google to authenticate for Microsoft Entra (when Microsoft Entra was configured as the OIDC Provider for the CHT), the Microsoft login page seemed to anticipate that the Google authentication was not allowed in the webview page and instead redirected the user into a devices auth flow. Unfortunately, this flow (on top of being a generally bad user experience) did not successfully complete the login in the cht-android app.

Expected behavior
SSO login with a Google OIDC provider (or proxied Google authentication) should work in cht-android (without using the device auth flow).

Environment

• Instance: 4.20.0+
• Android Version: 14
• App Version: 1.5.2

[jkuester]

As briefly mentioned on the previous issue, I think we might have to investigate using an Auth Tab instead of just keeping the login flow inside the root webview.

Interestingly we might be able to build on our previous work here. I am thinking that in the UrlHandler if we detect that the URL we are opening contains the expected redirect_uri for OIDC Login, then we can just pop an Auth Tab (similar to how we pop a child-webview for 3rd-party URLs). The only real complexity will be figuring out how to get the redirect back into the root webview with the authorization_code at the end of the login flow... (Though, that cannot be so hard since it is basically the whole purpose of these Auth Tabs...)

[icrc-fdeniger]

thanks @jkuester the fix was too easy to be realistic :)
What about https://docs.communityhealthtoolkit.org/building/branding/android/#android-app-links-verification
Is it something that could help ?

[jkuester]

I don't think so. 😞 @mrjones-plip and I already tried tinkering with that a bit to see, but as far as I could tell, hitting a 302 during normal browsing in a webview would not trigger the logic. It seems to need the user to actually tap a link. The main problem I see is getting the user back to cht-android at the end of the login flow. E.g. if we pop the default browser to run the OIDC auth (instead of using a system webview), then it seems like the user ends up just getting logged into the CHT webapp running in the default browser (and does not make it back to the cht-android webview with the authorization_code.

[icrc-fdeniger]

During my test with my phone, I had the choice to redirect the SSO call to the Android App and it seems it was working... Will go on my tests
But maybe it's due to the fact we are using Microsoft Entra ID and you are using Google Auth

[jkuester]

Okay, I ended up doing a deep-dive in this today. I was able to confirm perhaps the same behavior that @icrc-fdeniger was seeing where redirection from within the default browser (e.g. Chrome) would trigger the Android verified app link logic and be sent to the cht-android app. (As opposed to the behavior of redirects in a child webview which did not seem to trigger the app link redirection when I tested it before... 🤷).

Whatever the case, this redirecting to the app link is crucial because it makes it trivial to implement the OIDC login flow from within an Android Custom Tab. This is what I have done in #405. Things seem to work for the Google OIDC flow, but we still need to test the Entra > Google Guest Account workflow.

---

While the happy path here does work (in my limited testing), it feels a bit narrow. In particular, I observed some weird behavior in my testing where the cht-android login would not succeed when the Chrome app was open in the background. Basically, with the Chrome app open in the background, I navigated to the cht-android app. There I tapped the "Login with SSO" button and got redirected to the Custom Tab. There I was able to login to my Google account and then was redirected back to the cht-android app (to the /medic/login/oidc endpoint with my authentication code). But, then I would be back at the login page with the error saying the SSO login failed. After some hours of debugging, I realized what was happening was that there was some race-condition or something where the /medic/login/oidc link (with the auth code) apparently is getting send to both cht-android (via the app link intent) and also is being "submitted" in the default browser too (not in any visible tab, though). I came to this conclusion after noticing that every time I got the inexplicable login error in cht-android, I could open the url for my CHT instance in the default browser and would already have a valid CHT session. So, the reason for the login error in cht-android was that the auth code was no longer valid because it had already been submitted by the browser.... However, I do not observe this same race-condition when doing the OIDC login flow with the Chrome app closed ("Forced stopped"). In that case the login flow works as expected (with no CHT session magically manifesting in the browser).

Perhaps this is just some weird artifact of my emulated Android and cannot actually be reproduced on a normal Android device? More testing is necessary here to confirm if this is actually a problem....

@mrjones-plip could you maybe try a bit of testing here to see how it works for you? I have actually configured https://gamma.dev.medicmobile.org/ for SSO login via Google and added a CHT user associated with your medic.org email. I think my Google OIDC settings will let any member of the medicmobile org login. 🤞 Here are some pre-built apks for gamma (with the code from my PR):

medicmobilegamma.zip

[mrjones-plip]

yeah! I'll jump on some testing tomorrow and report back - stay tuned!

[mrjones-plip]

@jkuester - yes - I confirm your findings about Chrome needing to not be running. I tested on a Pixel 4a running Android 13 running cht-android-SNAPSHOT-medicmobilegamma-arm64-v8a-release.apk

First attempt (sorry forgot to record):

1. Launch CHT Android, click "Login with SSO"
2. Am in a web view for Google login, go through google login, including TFA with my NFC Yubikey
3. end up at CHT logged in

Second attempt (see video below)

1. wipe storage for CHT Android so I'm logged out
2. Launch Chrome
3. Launch CHT Android, click "Login with SSO"
4. a few redirects, sees I'm already logged via ID Provider, sends me back to CHT but with a login error Unexpected error while logging in. Please try again
5. force quit chrome
6. Launch CHT Android, click "Login with SSO"
7. end up at CHT logged in, "Fetching info..."

login.2nd.appempt.mp4

[mrjones-plip]

What's weird to me, but I guess makes sense given where the data is being stored, is that to logout of the CHT App and the OIDC Provider, you need to clear the data for both CHT Android AND for chrome. Here's a video of walking through those steps (a bit long/rambling as I stumble through the steps and guess how to do it (shout out to SO for how to ffmpeg out the part where my password was shown on screen briefly!))

note though that chrome is very much running at the end when I successfully log in though! This only works on first login though.

fumbling.about2.mp4

[jkuester]

@mrjones-plip thanks for confirming the behavior! 👍 😞 I spent a bunch more time this afternoon reading and exploring possible fixes for this. Unfortunately, I was never able to find any solid docs explaining the behavior or how to resolve it. 😬

Instead, though, I ended up doing a bit more re-factoring of the cht-android logic for handling app links so that the links launch directly into the activity handling the webview (instead of how it previously was launching in to an interim singleton activity which would then re-launch the activity with the webview with the link). Now, when you hit the re-direct at the end of the OIDC login flow to go back to the app url, the user is taken straight to the original activity that started the login process to load the link with the auth_code. The end result of this change is that I no longer see the race condition! (Or at least cht-android wins every time... 🤔 ) This logic has been added to my PR for additional testing/review.