Strategies for deploying Hydra at scale and/or in multi-tenant scenarios

ORY Hydra
#1

Hi,

We’re looking to use Hydra for our oAuth implementation and are wondering a few things related to deploying Hydra at scale.

our background
We offer a multi-tenant SaaS solution globally with Kubernetes clusters on multiple continents. The data for each tenant lives in only a single Kubernetes cluster and (through DNS - each tenant has a unique subdomain) we route all traffic related to the tenant, including all requests related to oAuth to the correct cluster.

Note: in this topic, when I say one Hydra (instance), I mean multiple Hydra processes connected to the same datastore.

Hydra deployment options
Given our overall deployment structure, we could deploy either:

  • a single, global Hydra
  • one Hydra per cluster
  • one Hydra per tenant.

These deployment options lead us to two questions outlines below

Question about oAuth Client registration
Regardless of which Hydra deployment option we’d go for, we have the requirement that any 3rd party that wants to register an oAuth Client with us, should only have to do so once.

This raises the first question: does the fact that we want 3rd parties to register their oAuth client only once mean that our only option is to have a single, global Hydra deployment?
Or would it work if we ourselves take care of creating the oAuth client on each Hydra deployment we have with the same details (and distribute any updates to/deletes of clients)?

As far as we can reason, the later should work just fine, as long as the clients are created with the same details, including the client_secret, on each Hydra instance. Is this correct or are we missing something?

Question about sharing one Hydra instance between multiple tenants
Questions related to this have come up on the Ory forum and in GitHub issues before and in some of those discussions it was said that from the perspective of security it was best to isolate tenants by running a single Hydra instance per tenant.

Given that this would be a significant overhead (not to mention the single oAuth Client registration challenge mentioned above): why this suggestion was made? What are the security risks of using the same Hydra instance for multiple tenants?

As far as we can see, as long as the database is secured, Hydra is the only one accessing it and Hydra itself doesn’t have a security issue, there shouldn’t be an issue with multiple tenants being on the same Hydra instance

Hope our questions are clear,
Paul

3 Likes
Best practise to support subdomain-based multi-tenancy
#2

Tnx for the likes :slight_smile:

But I’m curious about/eager to get some answers/insight/comments to the questions and ideas outlined above.

Paul

#3

This raises the first question: does the fact that we want 3rd parties to register their oAuth client only once mean that our only option is to have a single, global Hydra deployment?

You need one global datastore. Check out CockroachDB for planet-scale SQL. You do not want to keep data “in synch” between different datastores, it will lead to issues, and potential vulnerabilities if done wrong.

As far as we can reason, the later should work just fine, as long as the clients are created with the same details, including the client_secret, on each Hydra instance. Is this correct or are we missing something?

You are missing a lot, clients are not just dumb objects in the store, they implement important business logic that touches tokens and vice-versa.

Given that this would be a significant overhead (not to mention the single oAuth Client registration challenge mentioned above): why this suggestion was made? What are the security risks of using the same Hydra instance for multiple tenants?

You’re lacking isolation, but it depends on your specific use case if that’s bad or not.

As far as we can see, as long as the database is secured, Hydra is the only one accessing it and Hydra itself doesn’t have a security issue, there shouldn’t be an issue with multiple tenants being on the same Hydra instance.

Incorrect. If tokens should only be valid for one tenant and you misconfigure something, then a token might be valid for more than one tenant.