Hi, Supabase Auth Engineer here. Interesting, just wondering if there's a reason behind choosing to roll your own iDP instead of using one of the big ones out there (Okta, Azure, GSuite) ?
Disclaimer: I haven't built this yet (primarily because it's too hard today).
I want to build self-hostable servers, to give our customers the option of privacy and easier compliance.
In that arrangement, there'd be:
- Our main / central server, for regular SaaS customers. It also provides public assets ("knowledge bases" in this case, but it could be anything - even just licensing info) that all signed-in users have access to. This would be the iDP.
- Many self-hosted clones of our central server, per customer
Because the central server has the most up-to-date shareable assets, which might be ahead of any upgrade schedule a self-hosted customer has, they'd want their signed in employees to have transparent access to those latest ones too. I.e. without the extra friction of additional sign-in.
tl;dr the ability to offer our customers an easy self-hosted option of our Supabase platform (with limited federated access to central data) is highly desirable, now that even SMEs request better infosec. Doing it all inside a Supabase Docker - rather than mixing in Okta - is what makes it maintainable and easy to share.
--- EDIT ---
This use-case could be written more simply:
- There's a platform/app server (built on Supabase). Customers can optionally self-host it for their business.
- There's a data server (also built on Supabase, but not self-hosted), that provides shareable assets, even to self-hosted servers.
My goal is that it's _seamless_ for self-hosted users to access the data server.
So the data server would need to be an iDP.
My preference for Supabase to do this (instead of Okta), is because offering a self-hosting option is currently an intimidating maintenance burden, so fewer moving parts (no Okta) is desirable.
You can use one Supabase Auth project to do all of your user management. You can use the JWTs issued by this project across any other system. You need to configure those systems to "trust" those JWTs, usually by sharing the signing key (JWT secret) with them. They can then base their allow / deny decisions on the JWT.
You can even do this with as many Supabase projects you want. You don't have to use Supabase Auth with all of them. Do note that once you use physically different machines, you need to sync them up and that's quite a big can of worms.
Alas I envisage this being across many machines.
(I'll edit the previous post for brevity)