When creating a jwt/oicd auth you have to provide a callback url which matches a callback url on the auth provider. Some auth providers allow you to have a wildcard (“https://*.gitpod.io” )
We have an issue where our development env is “on the cloud” and we get a different dynamically created url for each workspace we start
The app we’re developing uses vault with Auth0 to authenticate - but we’re getting callback errors because we obviously don’t know the hostname in advance and so can’t set up the callback url’s in vault
It’s for auth. In order to call the vault api to set up a new redirect, every developer would then need write access to the oidc roles api every time they fire up a new workspace. Certainly doable, but they would need a token pre-defined that allows this access … not what I would call secure
if the provider (auth0) allows for a global pattern like https://.gitpod.io (they do) then specify a callback url pattern like https://.gitpod.io in vault the config and allow the client to send the callback as an option to the initial authentication call so that vault could verify that the supplied url matches the stored pattern and then pass it on as the callback url
ie: Auth0 callback is https://*.gitpod.io
we could manually create a role with 10 callbacks
Using the method above we would create a role with a callback of https://*.gitpod.io.
Client passes https://machine1.gitpod.io as a parameter to the oidc login , vault verifies that it matches *.gitpod.io and uses https://machine1.gitpod.io as the callbackurl passed to auth0
I struggle to see why this method is any less secure than manually specifying 10 callbacks
I asked if it was the Vault auth method or identity provider you’re using here, so “auth” sounds like an abbreviation for “auth method” but the rest of your message gives the impression you’re actually using the identity provider…
Vault can play multiple roles in an OIDC setup. Please can we first establish which one? Or multiple? it is playing in your environment?
Ah… So the slightly unusual thing about your deployment is that rather than having one Vault instance, you’re embedding a new instance of Vault into each development environment your developers create?
Maybe this it the problem. The browser based OIDC flow is really designed for people, not for systems.
So if you are wanting a user to login to Vault then OIDC could be a good choice. The flow would be user goes to Vault → OIDC provider → Vault (now logged in).
Alternatively you could use OIDC to login to your web application: App → OIDC provider → app (with a login token from your OIDC provider)
If you are wanting your app to login to Vault that is something totally different, and not something you’d look at OIDC for. You would generally have the app login to Vault (e.g. upon startup) using something like AppRole, Kubernetes or AWS auth. Vault doesn’t know/care who is behind the app - it just sees calls from the app, with it being the app’s responsibility to check any end user’s permissions.
Alternatively you could have the app pretend to be the end user. With this method you’d have the user login to Vault and then provider the resulting token to your app. It could then pass that token to Vault whenever it makes API calls. This is not recommended for several reasons. Firstly you’d need to ask the user to login to Vault and provide the token to your app, which is going to be a fairly horrible user experienced. Secondly your app now has the user’s Vault token which is pretty bad from a security point of view - that token has whatever permissions the user has, which is quite possibly a lot wider than what the app actually needs.