Dynamic host url and oidc callback

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

Has anyone else has this issue ?

It’s not entirely clear which side of Vault’s OIDC support you are using - the auth method or the identity provider?

Either way, pre-configuration of OIDC redirect URLs is a part of OIDC’s security model - so you can’t just turn it off. You’d need to call the Vault API to set up each new redirect URL.

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?

Sorry for the confusion. I want to use Auth0 as the identity provider, so we’re using the JWT/OIDC api

The callback parameter is a required option for the role

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?

no, we’re using a central vault, but the application is running inside the environment we’re spinning up in the cloud.

So, we go to github, and open a branch. we can then launch an environment with apache, node etc running. The application is then exposed on a port . This env has a random name, so the application is running on (for example) https://my-foobar-iq5npdrsvsegdyt.ws-eu47.gitpod.io:4200/

the problem is that we have no control over the iq5npdrsvsegdyt.ws part :wink: So we cannot pre-configure the callback in the oidc role

OK, I’m back to being confused then, because with this design, the callback URLs for the OIDC auth method to Vault, are supposed to point at Vault, not other applications.

Maybe it would help if your explained more about how you’re application fits into this? As the parties involved with using the OIDC auth method to Vault, are:

  • The identity provider (Auth0 here)
  • Vault
  • The user and their browser

There’s no room for a 4th party, your application, in this flow as I understand it.

ok, I see where you’re coming from. I’ll have a look at what I’m doing wrong.

In the meantime, lets say that I am doing this …

how would we go about sorting this ?

I don’t really understand what your goal is, so I’m not sure what to say unless you can explain more what you’re trying to achieve?

ok, let’s take a step back. I’m perhaps completely muddled regarding the login flow.

I am writing a web app. My web app needs to login to vault, using oidc. My app sends the initial login request to vault. What happens from here on in ?

My flow is:

App → start oidc login process, gets auth url to call. Browser is redirected to the url for auth
App->login to oidc auth provider (auth0 , google etc)

** At this point the callback url is called with the code, nonce and state value **
if the callback is to vault , how does the browser get back to my application url ?

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.