top | item 35556744

(no title)

paradaux | 2 years ago

What I'd love to see with this is a way to use supabase auth itself as an idP/SAMP provider. Have your tools (back-office tools and what not) written in native supabase, or have multiple supabase projects with the one shared auth system. Could be better UX for Sysadmins than OpenLDAP and so forth.

I'm currently building something similar to just do that on top of supabase for work. Happy to see the developments with Supabase Auth anyway.

discuss

order

kangmingtay|2 years ago

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) ?

andymitchell|2 years ago

I'm not the OP, but I do have a request here too.

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.