search

hashicorp / vault-plugin-auth-jwt

A Vault plugin to allow authentication via JWT (and OIDC) tokens
Mozilla Public License 2.0
100 stars 61 forks source link

Azure OIDC fails if using custom signing keys #75

Open stuart-c opened 5 years ago

stuart-c commented 5 years ago

Describe the bug Login fails with a failure to verify signature error if Azure is using custom signing keys for the integration. Looking at the Azure documentation the OpenID discovery URL needs to have ?appid=xxx appended to return the correct signing key details. Without this set the custom keys aren't returned and Vault fails to validate the JWT signature (no key found).

Looking at the code I can't see a way to add this query string parameter or override the discovered signing keys/URL.

To Reproduce Steps to reproduce the behavior:

  1. Setup OIDC authentication as per the instructions in the documentation.
  2. Ensure Azure is using a custom signing key
  3. Attempt login
  4. Check error log for returned JWT
  5. Decode JWT to find kid used to sign
  6. Visit discovery URL to find key URL and then visit.
  7. Verify key isn't listed
  8. Visit discovery URL with query string parameter to find key URL.
  9. Verify signing key is now returned

Expected behavior Vault would have a mechanism to either allow the query string parameter to be appended to the discovery URL (would require go-oidc changes) and/or allow key URL to be overriden (instead of it being taken from the discovery URL)

Additional context go-oidc have a few Azure related issues listed, but not directly related to this issue: https://github.com/coreos/go-oidc/issues/212

stuart-c commented 5 years ago

Azure documentation:

https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc#fetch-the-openid-connect-metadata-document

shannonrdunn commented 4 years ago

this is affecting is too.

allowing key URL to be overridden would work for us, or another work around? Any plans on implementing one of them?

Thanks!

kalafut commented 4 years ago

Not yet planned, but I'd like a workaround for this. This seems like Azure-only behavior (or at least I've not heard of other cases) that would best as an Azure-specific config.

jefferai commented 3 years ago

One possibility would be to check if the provided URL contains query params and if so, treat it as an absolute override URL. If not, treat it as a base URL for discovery.

kalafut commented 3 years ago

@austingebauer @calvn Now that we have provider-specific configs this could be worth a relook.