Where can I find the debug logs for OIDC?

Hello,

I am trying to integrate our OIDC provider with Vault. When creating the role, I specified the option verbose_oidc_logging=true. I also enabled debug logs by setting the VAULT_LOG_LEVEL environment variable to debug.

I don’t know whether that’s relevant, but I am deploying Vault as an HA cluster with the Integrated Storage backend in Kubernetes.

I am testing OIDC and it’s not working. I can see the browser pop-up showing our OIDC provider. I then enter all the required details, but Vault fails to login. When I check the output of the Vault pods (using kubectl logs), I can’t see anything related to OIDC…

Where can I find the logs related to OIDC?

Many thanks for your help!

This logging is just written along with the rest of the general Vault logging, to the stderr stream of the Vault process - which I would have guessed would end up in kubectl logs. Do you see any logging from Vault there?

Hi @maxb ,

Yes, I do see lots of logs from Vault, but nothing related to OIDC as far as I can tell…
I even monitor the logs in real-time while I try to perform an OIDC login, and nothing gets logged out…

Hmm. About the only thing I can think of is that something is going wrong that is not covered by the additional logging turned on by verbose_oidc_logging.

Which is very possible, as that setting only turns on two extra log messages for requests to path auth/<mounted-name>/oidc/callback, logging the received ID token and results of parsing it, with messages containing OIDC provider response.

Are you able to give more information about what exactly fails - perhaps using your web browser’s developer tools to identify the HTTP request which fails?

To gather extra data, can you report on how a CLI-based (i.e. vault login -method=oidc) login works too?

This is what the verbose OIDC logging looks like - this is me logging into my test Vault using Google as the OIDC provider:

[DEBUG] auth.oidc.auth_oidc_a345ffb8: OIDC provider response: id_token=eyJREDACTED.eyJREDACTED.xxxxxxxxxxx
[DEBUG] auth.oidc.auth_oidc_a345ffb8: OIDC provider response: claims="{\"at_hash\":\"GFNogRzwSPEqWB3lL67wrg\",\"aud\":\"REDACTED.apps.googleusercontent.com\",\"azp\":\"REDACTED.apps.googleusercontent.com\",\"email\":\"REDACTED\",\"email_verified\":true,\"exp\":1651944456,\"family_name\":\"REDACTED\",\"given_name\":\"REDACTED\",\"iat\":1651940856,\"iss\":\"https://accounts.google.com\",\"locale\":\"en-GB\",\"name\":\"REDACTED\",\"picture\":\"https://lh3.googleusercontent.com/REDACTED\",\"sub\":\"REDACTED\"}"

That’s all - just those two lines - and if things got that far the login is quite possibly going to succeed anyway.

Sample configuration for setting up Google-based OIDC login in Vault:

vault auth enable -path=google oidc
vault auth tune -listing-visibility=unauth google

vault write auth/google/config \
  oidc_discovery_url=https://accounts.google.com \
  oidc_client_id=<value from Google Developers Console> \
  oidc_client_secret=<value from Google Developers Console> \
  default_role=default

vault write auth/google/role/default \
  user_claim=sub \
  oidc_scopes=email,profile \
  allowed_redirect_uris=https://vault.example.local/ui/vault/auth/google/oidc/callback,http://localhost:8250/oidc/callback \
  verbose_oidc_logging=true

Since I’ve deliberately the auth method at a non-default name, logging in from the CLI would look like:

vault login -method=oidc -path=google

The Vault docs on navigating the Google Developers Console to get hold of a client ID/secret can be found at OIDC Provider Setup - Auth Methods | Vault by HashiCorp and the redirect URIs that need to be input are the same as the ones specified to Vault as allowed_redirect_uris in the above shell snippet.