Vault OIDC identity provider web UI redirect doesn't work on Android (Chrome) after authenticating with Google OIDC

[siepkes]

Describe the bug

When having an Android app authenticate with the Vault OIDC identity provider and having Vault in turn authenticate the user with Google OIDC the redirect back to the app from Vault doesn't work. So after logging in with Google you get correctly redirected to Vault but then Vault doesn't redirect back to the app. Chrome (104) on Android will show the Vault logo loading animation forever.

When the user uses an Android app to authenticate via the Vault OIDC identity provider and directly authenticates to Vault with for example the userpass authentication method the user does get correctly redirected back to the app.

When the user tries to login to the Vault web UI with Google OIDC this also works correctly.

So the problem only occurs when one tries to authenticate in an Android app and uses the Vault OIDC provider which then in turn uses Google OIDC (and perhaps other OIDC providers) authentication.

Environment:

• Vault Server Version 1.11.2:
• Vault CLI Version 1.11.2:

[austingebauer]

@siepkes - Thanks for reporting this. I've successfully tested the same flow (OIDC auth within app using OIDC provider) in the past using a desktop browser. I'll try to reproduce and let you know what I find.

[siepkes]

I noticed too that on the desktop everything works fine. I suspect it is some weird interaction with the embedded Chrome browser which is used when doing OIDC on Android.

I also tried setting Firefox as default browser (so the embedded browser used for OIDC would be Firefox) but I then encountered an "cannot read properties of null" like error upon returning to Vault from Google.

The library I used on Android was https://github.com/FormidableLabs/react-native-app-auth.

[siepkes]

I thought to debug this a bit further so I hooked up Android Chrome to my desktop Chrome and the following exceptions is thrown (multiple times, basically every couple of seconds):

vendor-9435df1547cf2481cbe0bbe5b0f8c613.js:2693 Uncaught (in promise) TypeError: m is not a function
    at vendor-9435df1547cf2481cbe0bbe5b0f8c613.js:2693
    at vendor-9435df1547cf2481cbe0bbe5b0f8c613.js:2516
    at e.track (vendor-9435df1547cf2481cbe0bbe5b0f8c613.js:3177)
    at m (vendor-9435df1547cf2481cbe0bbe5b0f8c613.js:2516)
    at vendor-9435df1547cf2481cbe0bbe5b0f8c613.js:2693
    at vendor-9435df1547cf2481cbe0bbe5b0f8c613.js:2516
    at e.track (vendor-9435df1547cf2481cbe0bbe5b0f8c613.js:3177)
    at m (vendor-9435df1547cf2481cbe0bbe5b0f8c613.js:2516)
    at O.get (vendor-9435df1547cf2481cbe0bbe5b0f8c613.js:2191)
    at n (vendor-9435df1547cf2481cbe0bbe5b0f8c613.js:12049)

Oddly enough, sometimes the redirect back to the app works. But most of the time it doesn't.

I managed to capture a HAR one time when the redirect back to the app actually succeeded:

success-vault-1_12_0.zip

This a capture of when Vault fails to redirect back to the app and the user sees the spinner (basically forever):

failure-vault-1_12_0.zip

[austingebauer]

Thanks for this additional information, @siepkes! It looks like an issue in how our UI code handles the redirect. I've added the ui label and will let the team know.