Custom DB Connection and Login Script Per Kubernetes Pod?

I have an application where each client can have multiple users. Each client gets their own specific deployment of the application that runs in its own kubernetes pod. Currently, each client also maintains its own user database via the Parse open source system. We are in the process of migrating to leverage Auth0 for login purposes. When a user hits the app, they are hitting a url specific to the client instance ex:

app.com/c/[client_id]/

I’m leveraging Auth0 lock to present the user with a login UX that we will be replicating against all of our other products. I’ve currently got a custom connection setup at the Auth0 application level, that uses a custom login script. The login script needs to be able to make a post request to the “client specific” parse endpoint. I would love to be able to know if there is a way to accomplish this without needing to setup a custom connection per client that we have (currently there are ~1000 users spread across ~300 unique clients - each client runs in its own kubernetes pod).

Currently I have a solution in place that works with a single client, as I have manually setup the connection and login script to make the post request to the specific client endpoint.

If I go the route of setting up a custom connection per client, are there limits to the number of custom connections that can be setup for a tenant?

Do you have any other recommendations as to how to go about implementing this. The current constraints are that we are not migrating the identity store to auth0, and as part of the “login” procedure, the Auth0 login scripts need to make a post request to the client specific Parse server.

Our usual recommendation here is to create multiple connections. This makes sense because in reality these users are in multiple stores, so it’s good to have that separation in Auth0 level as well.

You may find this doc on allowed entity limits useful: Entity Limit Policy (TL;DR: number of allowed connections depend on your subscription)
And if you are going that route, you may find it easier to use the Auth0 management API or Deploy CLI to manage the connections, rather than the Auth0 dashboard itself.

It will be possible to keep a single custom database connection only if the parse endpoint can be deduced from the email address. By the email domain, for example. The DB scripts receive only the email (and sometimes the password), and the script needs to call the correct endpoint. I must warn here though - there could be potential problems in the long term. For example, what if a user with the same email address lives in two Parse instances?

Thanks for the reply. My follow up question is, is the limit to the number of Custom Connections per tenant 100? If so, then I might need some suggestions on an alternative approach as I need to be able to setup at least ~300 custom db connections.

The allowed number of connections depends on the subscription. For self-service subscriptions like Developer and Developer Pro the limit is 100. With an enterprise subscription more connections can be created, even 300. (Not trying to sell anything here, just explaining the pricing :slight_smile:)

But I agree that this could be overkill if these ~300 user stores only have ~1000 users in total. I guess there’s no possibility of identifying the server based on the user’s email address?