You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Worth separating two things that often get conflated on this topic, since it might save someone a detour.
Vault's jwt auth method covers two role types. oidc is the interactive one — the browser redirect, auth code exchange, callback listener. jwt is the non-interactive one: you present an already-signed token and get a Vault token back. This issue is about the first.
If anyone lands here actually wanting the second — CI jobs, GitHub Actions OIDC, Kubernetes or SPIFFE workloads — it's a much smaller thing than the OIDC flow. It's one POST auth/<mount>/login with { jwt, role }, where role is optional and falls back to the mount's default_role. We added it to node-vault-client recently if it's useful as a reference implementation, though to be clear it doesn't help with the ask in this issue: interactive oidc is deliberately out of scope there too, for the same reason it's awkward here — a headless service doing background token renewal has no browser to redirect to.
One gotcha that cost us time, and which applies whichever library you use: Vault requires the role to bind the audience your token carries, and it doesn't catch the omission when you create the role. As long as the role has some other bound constraint it's accepted, and you only find out at login:
audience claim found in JWT but no audiences bound to the role
So bound_audiences has to match the aud your IdP actually mints. With GitHub Actions that means core.getIDToken('vault') and bound_audiences=vault have to agree — calling getIDToken() with no argument uses GitHub's default audience and won't match.
Activity
amity0 commentedon Apr 28, 2021
any updates on this issue?
aviadhahami commentedon Nov 10, 2022
Hey @aprabh001c not afaik
Feel free to PR this :)
Closing the issue for now
aviadhahami commentedon Nov 10, 2022
feature request --> support OIDC login
mikicho commentedon Dec 8, 2022
We also need
oidclogin.@aviadhahami not sure why did you close this issue.
aviadhahami commentedon Dec 15, 2022
@mikicho mb
We can reopen it
I'm still waiting for full permissions from repo owner
mikicho commentedon Dec 15, 2022
Thanks! 🙏
aviadhahami commentedon Jul 20, 2023
@mikicho heya - do you mind helping with implementing this?
mikicho commentedon Jul 20, 2023
Hi. I'm sorry, but I currently don't have the time to take care of this.
aviadhahami commentedon Jul 20, 2023
Likewise; as of now this is frozen then 🥶 🤷
kurok commentedon Sep 1, 2026
Worth separating two things that often get conflated on this topic, since it might save someone a detour.
Vault's
jwtauth method covers two role types.oidcis the interactive one — the browser redirect, auth code exchange, callback listener.jwtis the non-interactive one: you present an already-signed token and get a Vault token back. This issue is about the first.If anyone lands here actually wanting the second — CI jobs, GitHub Actions OIDC, Kubernetes or SPIFFE workloads — it's a much smaller thing than the OIDC flow. It's one
POST auth/<mount>/loginwith{ jwt, role }, whereroleis optional and falls back to the mount'sdefault_role. We added it to node-vault-client recently if it's useful as a reference implementation, though to be clear it doesn't help with the ask in this issue: interactiveoidcis deliberately out of scope there too, for the same reason it's awkward here — a headless service doing background token renewal has no browser to redirect to.One gotcha that cost us time, and which applies whichever library you use: Vault requires the role to bind the audience your token carries, and it doesn't catch the omission when you create the role. As long as the role has some other bound constraint it's accepted, and you only find out at login:
So
bound_audienceshas to match theaudyour IdP actually mints. With GitHub Actions that meanscore.getIDToken('vault')andbound_audiences=vaulthave to agree — callinggetIDToken()with no argument uses GitHub's default audience and won't match.