Are there any practical limitations on the number of generic social providers in Ory Cloud?

[PlasticLizard]

Hello,

I have a very general question regarding our system design. We are hoping to use Ory Cloud for our application, an aspect of which allows our users to configure their own OAuth apps.

For example, we allow them to connect their own Slack App to our platform, and they would provide their own Client ID and secret and we would provide callback URLs & data processing (not for authentication, but for processing messages to and from slack).

We are considering delegating all of the OAuth to Ory, but this would require us storing some hundreds or thousands of generic OAuth configurations in our Ory cloud instance which we would update via the admin API whenever they create or update a connection to a provider.

Is this practical, or would it be better for us simply to maintain an internal database table of these OAuth configs and manage this aspect of our app outside Ory.

Thanks for any insight!

Nathan

[aeneasr]

Great question! It depends a bit :) Our managed UIs would probably render a thousand buttons ("sign in with slack workspace A, sign in with slack workspace B, ...") if you add a thousand connections. To make this process better, you could bring your own login, registration, and settings screen and only show those slack connections relevant to the user!

Hope this helps :)

[PlasticLizard]

Yes, that was our plan, as we will already have some dozens of providers for various integrations that would need to be filtered case by case anyway. Thank you very much for the amazingly fast and helpful response, glad to know there aren't any technical limitations to this strategy.