Using a single oathkeeper in front of multiple Hydra deployments (multi-tentant)


We’re trying to figure out a proper deployment model for Hydra in a multi-tent scenario.

We’ve reached the conclusion that in order to have true multi-tenancy support on the oauth/oidc side (with Hydra), we need to deploy a single Hydra instance per tenant and distribute the oauth client registrations between these Hydra instances (possibly using

We’re now looking into how oathkeeper fits into this and it seems like all the urls you configure in oathkeeper, for example the token and instrospection urls for the oauth2_introspection authenticator must be absolute, which would mean (afaics) that we’d have to run a oathkeeper per tenant as well. Am I understanding that correctly?

If so, would you consider a PR that would allow relative urls for such config and logic to prepend the domain of the current requestUrl to it?

And what about a PR to force the iss claim in a JWT token to match the current requestUrl, as adding the urls of each tenant in the trusted_issuers config is not really scalable/manageable



With recent releases of oathkeeper, you can configure every “handler” (e.g. oauth2_introspection) globally and per route. This means you could have different introspection endpoints per route.

Hope this helps!

So you’re suggesting that instead of using wildcard match urls (https://<.*>.example/com/…, to have one route definition shared by all tenants for a specific route on our api), to create a route per tenant for each specific route in our api?

Not sure if that is scalable… Say our api needs approx. 100 individual routes. With a 1000 tenants, that would already be 100k routes configured in oathkeeper. 10k tenants: 1mln routes in oathkeeper.

Does oathkeeper scale like that?

You can always shard this when you hit scalability issues, it’s just a practical solution to your problem. I’m assuming you don’t have to deal with 10.000 tenants yet.

While we’re not at 10k tenants yet, we’re growing fast :slight_smile:

I guess we could setup a sharding infrastructure, but I wonder if there aren’t other options

I now realize that the approach I suggested before won’t work, as the introspection url is an internal url, while the (api) request that oathkeeper is handling is an external request.

So, I was wondering if maybe oathkeeper is already sending the host/x-forwarded-host header of the original request with call to the introspection endpoint, but I don’t think it is.

Found some (related/sorta) similar cases (, for example) and this MR from a few days ago:

I was wondering if you’d accept a PR that adds config options that makes oathkeeper forward certain headers from the inflight (api) request to the introspection request

Yeah, I think that’s definitely something that would be accepted. Maybe something like forward_host or something similar.

Cool, will create a case on the oathkeeper repo for further discussion and start working on a PR