Regression: OIDC Login Hangs

[braunsonm]

Describe the bug
Starting in 1.9.1, our OIDC login flow will simply hang in the popup window. This may be a regression caused by #13231 or #13298 @fairclothjm @austingebauer

The popup window will go to Microsoft (in my case) which returns a 200, on the page that says "Completing the sign-in process.." it hangs.

I can see the network call to https://#.microsoftonline.com/<snip>/oauth2/v2.0/authorize and then the callback to https://vault.example.com/v1/auth/oidc/oidc/callback which seems to do nothing after that.

To Reproduce
Steps to reproduce the behavior:

1. Initialize Vault like so. This assumes you have an Azure AD to use

vault auth enable oidc
vault write auth/oidc/config -<<"EOH"
{
   "oidc_client_id": "your_client_id",
   "oidc_client_secret": "your_client_secret",
   "default_role": "default",
   "oidc_discovery_url": "https://#.microsoftonline.com/<snip>/v2.0",
   "oidc_response_mode": "form_post",
   "oidc_response_types": [
    "id_token"
   ],
   "provider_config": {
      "provider": "azure"
   }
}
EOH
vault write auth/oidc/role/default user_claim="preferred_username" allowed_redirect_uris="http://localhost:8250/oidc/callback,https://vault.example.com/ui/vault/auth/oidc/oidc/callback" groups_claim="groups" policies=default oidc_scopes="https://graph.microsoft.com/.default profile"

2. Navigate to the UI and try to login with the OIDC provider
3. Popup will hang forever

Expected behavior
The login flow should not hang as it worked correctly in 1.9.0.

Environment:

• Vault Server Version (retrieve with vault status): 1.9.1
• Server Operating System/Architecture: Docker Image on Ubuntu 18.04

Vault server configuration file(s):

storage "file" {
  path    = "/vault/file"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 1
}

api_addr = "http://127.0.0.1:8200"
ui = true
log_level = "Trace"

Additional context
This worked in the version directly before 1.9.1.

This SAME bug happened in 1.8.0 which was a confirmed bug: #12239

[austingebauer]

Thanks for the report, @braunsonm. I'm having a closer look at this now. I also wanted to mention that the PRs you've linked as possibly introducing the regression are for a different OIDC-related feature (provider instead of client side OIDC auth). Will update you after trying to reproduce this shortly.

[braunsonm]

Oh my bad @austingebauer The last time this happened in 1.8.0 was due to an OIDC auth change so I incorrectly assumed this might have been related.

Let me know if I can be of any help!

[austingebauer]

Hi, @braunsonm. Following up with you that I was able to reproduce this issue using Vault 1.9.1. I also confirmed that the implicit flow works with 1.9.0. I'm actively looking into this and will post an update when I've found the cause.

[braunsonm]

Thanks @austingebauer I see your PR for it now.

Suggestion: Since this is the second time this same regression has been introduced in the past two minor updates, perhaps a test case would be a good idea around this flow?

[austingebauer]

@braunsonm - Absolutely! Happy to help.

That's a good suggestion. We do have some tests that use the implicit flow in the plugin repository, but they're from the perspective of the Vault CLI going through the OIDC flow. In this case, there was some coordination between browser windows that involves Javascript from both the plugin repository and Vault repository. Recent changes on the Vault side didn't take into account the Javascript on the plugin side. We're thinking of ways we can catch this failure to coordinate in the future (e.g., UI-based testing, code owner notifications). Apologies for these regressions, and thanks again for opening the issue.

[braunsonm]

This is still an issue with 1.9.2, did this not make it into the release?

[austingebauer]

@braunsonm - Unfortunately, this didn't make it in time for Vault 1.9.2. It'll go out with Vault 1.9.3. Sorry for the delay on getting this fix out. If you're not able to wait, one option would be to build v0.11.4 and register the plugin manually.

[archoversight]

@austingebauer is there somewhere where I can track how close the Hashicorp team is to releasing a new version of vault? This is affecting a lot of our users, and unfortunately due to being in a regulated environment we can't build from source.

[austingebauer]

@archoversight - I'm sorry, but there isn't a way to publicly track how close we are to publishing certain releases. We're targeting to get this bug fix released soon though (estimated end of January / early February).