OKTA OIDC login - not getting the claims I need/want

I’ve set up a okta OIDC app and configured vault according to https://github.com/ncabatoff/vault-1.1-webinar/blob/master/README-oidc.md. Login works if the user_claim is sub.

I try to set it to “preferred_username” which I’ve used with other OIDC applications and okta. With vault I only get this:

claim “preferred_username” not found in token

I’ve also set up okta to pass a groups claim which is also not passed. I can see that the groups claim should be passed in the token previewer in okta…

Enabeling verbose_oidc_logging I see this in the log:

OIDC provider response: claims={“amr”:[“swk”,“pwd”,“mfa”],“at_hash”:"", “aud”:"",“auth_time”:1591272834,“exp”:1591277580,“iat”:1591273980, “idp”:"", “iss”:“https://schibsted.okta.com”, “jti”:"", “sub”:“00u1ctd6mp51PYINY0h8”, “ver”:1}

So clearly no preferred_username or groups claim. If I change the user_claim to sub and remove the groups claim requirement it all works. BUT I need to give different groups of people access to different KV stores so that won’t do.

Has anyone used Vault with OKTA OIDC and gotten groups to work?

In Okta w/ OIDC I had a note that the only way to have the groups returned is to set Include in token type to ID (not Access)…
That was in Okta’s UI in Scopes >> Add groups scope >> Claims >> Add Claim

I had used this as a starting point: https://developer.okta.com/docs/guides/customize-tokens-returned-from-okta/overview/

I had fooled with the token configuration in okta with no real win.

After reading various docs refering to “fat tokens” and the scopes I realized that in some other setup I had set the oidc scope to “openid profile” and also “groups”. When I did that I got not only the preferred_username but also the groups claim.

More concretely, the oidc default role/role that is used for vault login needs something like this:

$ vault read auth/oidc/role/policy_by_group
Key                        Value
---                        -----
allowed_redirect_uris      [http://<internal server>:8200/ui/vault/auth/oidc/oidc/callback http://<internal server>:8250/oidc/callback http://localhost:8250/oidc/callback]
bound_audiences            [<openid client id>]
bound_claims               <nil>
bound_claims_type          string
bound_subject              n/a
claim_mappings             <nil>
clock_skew_leeway          0
expiration_leeway          0
groups_claim               groups
not_before_leeway          0
oidc_scopes                [openid profile groups]
role_type                  oidc
token_bound_cidrs          []
token_explicit_max_ttl     0s
token_max_ttl              0s
token_no_default_policy    false
token_num_uses             0
token_period               0s
token_policies             []
token_ttl                  0s
token_type                 default
user_claim                 preferred_username
verbose_oidc_logging       true

The key being the oidc_scopes setting including “profile” to get the preferred_username and some other claims and “groups” to get the groups claim.

The verebose_oidc_logging true was most enlightening. On centos/rh the log can be followed by “journalctl -u vault -f”

Can you share your vault write command to get the above configuration written to vault?


vault write auth/oidc/role/admin bound_audiences=“xxxxxxxx” allowed_redirect_uris=“http://xxxx:8200/ui/vault/auth/oidc/oidc/callback” allowed_redirect_uris=“http://xxxx:8250/oidc/callback” user_claim=“sub” policies=“secret_ro” oidc_scopes=“openid profile groups” groups_claim=“groups” verbose_oidc_logging=“false” token_policies=“admin” bound_groups=“HashiCorpVault_Admin”

I was on vacation. It looks like you found the right write command? Is it working now?

Hi, Thanks for the response. Yes. It is working now.

But, i still have not figure out how to read the oidc debug log effectively. I got a lot of logs. but, cannot tell if the token return is missing any claim.

mind to show some example of your log?



I’ve disabled debugging by now and the logs have expired. It was pretty plain that the group claim was included in the JSON in the log. It was like the snippet I posted originally just with a lot more content (since this was the minimal claim I originally got):

Thanks for sharing. Search through my audit log, cant see anything similar

What I have is something like this:

  • “request”:{
    • “id”:“7e8b6849-452f-a07a-0dc7-15a06f858213”,
    • “operation”:“read”,
    • “mount_type”:“oidc”,
    • “namespace”:{
      • “id”:“root”},
    • “path”:“auth/oidc/oidc/callback”,
    • “data”:{
      • “code”:“hmac-sha256:de6889fc4a36d6e7ae36daf1f7c2883542a450cda0de9fa06cb78a4c563347da”,
      • “state”:“hmac-sha256:0bee12f92f5e0cef0d5cdfc7a47e4275bbc10272583825ce2173f5c0673a72c6”},
    • “remote_address”:“”},
  • “response”:{
    • “auth”:{
      • “client_token”:“hmac-sha256:ac57616b07697cb1b25df9c4e6f8a8cb7af673aa54435b3e3ba4031c5914b974”,
      • “accessor”:“hmac-sha256:4ff283d489920baea66f0787f0b0942442b528def6e1d950fead5ef6350a93c4”,
      • “display_name”:“oidc-00udhbc2c6K8oHFEu4x6”,
      • “policies”:[
        1. “admin”,
        2. “default”],
      • “token_policies”:[
        1. “admin”,
        2. “default”],
      • “metadata”:{
        • “role”:“admin”},
      • “entity_id”:“ca8d92fd-2849-eb2e-2bbd-23ae69be315e”,
      • “token_type”:“service”,
      • “token_ttl”:2764800},
    • “mount_type”:“oidc”}


There should be a “claim=” somewhere in the responses if your configuration works at all. Does it work at all - without profile and groups claims?

I’m fiddeling with a different part of our ldap divestment right now but I’ll see what I can get logged and post here within some days.

Ah, I found it.
Its in the serverlog. not in the audit log.