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.