Vault: [UI] OIDC authentication not working with Stylus extension installed

[Kasama]

Describe the bug
When trying to authenticate with Google OIDC while having the Stylus extension installed, the popup window stays frozen for a couple of seconds (like in the image) then redirects to the /ui/vault/auth page again (second image), while the original one keeps waiting for the callback.

Judging by the url of the popup, it tried to redirect correctly, but in the wrong window.

To Reproduce
Steps to reproduce the behavior:

1. Run a development server nohup vault server -dev & (the problem happens in my production server aswell)
2. export the vault address export VAULT_ADDR=http://localhost:8200
3. Get the root token ROOT_TOKEN=$(cat nohup.out | grep "Root Token:" | cut -d' ' -f3)
4. Create an OAuth2 token in google cloud with http://localhost:8200/oidc/callback and http://localhost:8200/ui/vault/auth/oidc/oidc/callback authorized redirect urls
5. Suppose G_CLIENT_ID is a variable that contains the google auth client ID and G_CLIENT_SECRET is a variable that contains the google auth client secret
6. Run vault login $ROOT_TOKEN
7. Enable OIDC vault auth enable oidc
8. Configure OIDC vault write auth/oidc/config default_role=gmail oidc_client_id=$G_CLIENT_ID oidc_discovery_url=https://accounts.google.com oidc_client_secret=$G_CLIENT_SECRET
9. Configure default role vault write auth/oidc/role/gmail allowed_redirect_uris=http://localhost:8200/oidc/callback,http://localhost:8200/ui/vault/auth/oidc/oidc/callback bound_audiences=$G_CLIENT_ID policies=default user_claim=email oidc_scopes=email,profile
10. Test command line login vault login -method=oidc (should work fine)
11. Open vault ui on a browser with Stylus installed.
12. Select OIDC in the authentication dropdown.
13. Click the Google Sign In button to login with google.
14. See the problem
15. cleanup kill %1; rm nohup.out and delete created Google API Key

Expected behavior
Login into the UI should succeed

Environment:

• vault status:

Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    1
Threshold       1
Version         1.3.0
Cluster Name    vault-cluster-feb87f79
Cluster ID      6dee3c1d-ba55-040f-9de0-bdaf6e1045e4
HA Enabled      false

• vault version: Vault v1.3.0
• uname -a: Darwin Kasama 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64 i386 MacBookPro15,1 Darwin
• Firefox version: Mozilla Firefox 70.0

Vault server configuration file(s): any/default/not important

Additional context
I've noticed that when I successfully login in the popup window, the local storage gets populated with the OIDC information.
I think it's also worthy to note that the problem happened both in my work computer, my coworker's computer and my home computer.

If any further help is needed to reproduce the problem, please let me know

[jktr]

My Org seems to be hitting this issue as well.

Our Symptoms are identical: The browser-only OIDC flow in Firefox gets stuck in the pop up window, but with correct redirect and populated local storage as mentioned above. CLI login using Firefox works; Chrome works for both, too.

We're using a self-hosted GitLab instance as our OIDC Provider, so this issue probably isn't specific to google's OIDC flow.

• Vault v1.3.0
• Mozilla Firefox 70.0.1
• clients: Linux 4.12.14-lp151.28.32-default #1 SMP Wed Nov 13 07:50:15 UTC 2019 (6e1aaad) x86_64 x86_64 x86_64 GNU/Linux
• servers: Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux and Linux 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28) x86_64 GNU/Linux

[Kasama]

I've just tested and could reproduce in version v1.3.0. I updated the original post to reflect this version

[kalafut]

Interesting. I use Firefox (on MacOS) as my daily browser and am not seeing this. I typically test OIDC against a Gitlab account. Some misc questions (for either of you):

• Does Safe Mode (https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode) behave any differently?
• Are things stuck on the way out to the provider (i.e. you never see the Gitlab/Google screen), or on the way back post-login?
• Does it matter whether you're already logged in to the provider at the time you make the Vault login request?

cc: @meirish since you are probably most familiar with the redirect flow

[Kasama]

Indeed! In safe mode the redirect flow works fine.

Knowing that, I've tried disabling my extensions one by one and have narrowed it down to Stylus. Installing this same extension on chrome gives the exact same problem.

As for the other questions:

• Are things stuck on the way out to the provider (i.e. you never see the Gitlab/Google screen), or on the way back post-login?

They get stuck on the way back from the provider, after login

• Does it matter whether you're already logged in to the provider at the time you make the Vault login request?

It does not matter, it gets stuck either way.

---

Now I guess the issue is to find out why that happens only with Vault and not with every other website that uses a similar OIDC redirect flow. I'll try to investigate how the code for this flow works and were it gets stuck.

I won't close this issue just now, because I'd like to hear if @jktr's problem is the same or not.

[kalafut]

@Kasama Nice! Yep, I see the issue too if I install Stylus.

[Kasama]

I've found the culprit!

A polyfill of Stylus somewhere sets a value to the localStorage to validate if it exists, which triggers a StorageEvent that vault is listening to. But when vault goes to check for the event key, the key is actually _access_check instead of oidcState as it expects, then it returns and hangs.

I'll create a pull request with my naive fix, which I'm not sure is the best.

[Kasama]

I've also updated the original post and title to reflect the root problem

[jktr]

@Kasama: Yep, this seems to have been the issue on my end as well. It just so happened that I and all affected colleagues had Stylus installed.

Thanks for taking the time to further investigate the issue!