Earlier quoted context omitted.
> do you have an opinion on which enterprise-grade AuthZ provider works best with Supabase? Since you asked for my personal opinion, then I would say Postgres Row Level Security for AuthZ. RLS is as powerful as it is flexible. It's fully-integrated with the rest of the Supabase stack, and it's portable if you don't like supabase - just pg_dump and take it to your favourite Postgres provider. That said, I understand w…
If you need the flexibility of a system that can model both RBAC and ABAC and you also want you want a Zanzibar-inspired design, SpiceDB[0] is the only option that I know checks all the boxes (disclosure: I'm a maintainer). The UX definitely isn't optimized for Supabase, but I'd love to learn more about how that could be improved. I suspect it might be complicated if Supabase assumes RLS for everything. [0]: https://…
Supabase Auth: SSO, Mobile, and Server-Side Support
31–40 of 68 posts
Re: Supabase Auth: SSO, Mobile, and Server-Side Support
#32Re: Supabase Auth: SSO, Mobile, and Server-Side Support
#33who actually uses supabase at scale in production?
Re: Supabase Auth: SSO, Mobile, and Server-Side Support
#34Earlier quoted context omitted.
If you need the flexibility of a system that can model both RBAC and ABAC and you also want you want a Zanzibar-inspired design, SpiceDB[0] is the only option that I know checks all the boxes (disclosure: I'm a maintainer). The UX definitely isn't optimized for Supabase, but I'd love to learn more about how that could be improved. I suspect it might be complicated if Supabase assumes RLS for everything. [0]: https://…
While SpiceDB looks good. My only concern is if they will go the mongo route once they get more adoption and need to satisfy investors as opposed to customers/developers and make most of their features paid and leave the open source version hanging.
Glad to chat with anyone privately if they want more details.
Re: Supabase Auth: SSO, Mobile, and Server-Side Support
#35What 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…
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.
Re: Supabase Auth: SSO, Mobile, and Server-Side Support
#36One of the things that I really dislike about most auth providers is that it is very hard to implement login in your native UI. It almost always requires a redirect to a hosted UI page that is very clearly not your UI. We've found this a poor and potentially confusing user experience when you just need a form with username + password.
Question for Supabase: Is it possible to just have a form with username + password and POSTing the login details?
Re: Supabase Auth: SSO, Mobile, and Server-Side Support
#37hey hn, supabase ceo here this one is really 3 launches for auth: - SAML 2.0, for developers can add SSO to their own apps - PKCE: support for Mobile and server-side auth - Native Apple login on iOS We’ve been dogfooding SSO already and it stable. PKCE is going to be rolled out incrementally across the platform - we’ve tried to engineer it so that there are no breaking changes for your applications, but will exercise…
* It's not establishment of a "session", but a token set which you're issuing. * The authorization server will return those tokens after validating the code_verifier.
Also, be careful about PKCE on mobile platforms. Unless you're specifically mapping or restricting redirect_uris to an Android intent, on that platform, you're subject to replay attacks due to some cookie sharing in Chrome.
Re: Supabase Auth: SSO, Mobile, and Server-Side Support
#38So if anybody else got excited about multi-tenant SSO but was wondering how to implement it, the docs page is here https://supabase.com/docs/guides/auth/sso/auth-sso-saml . I'm super excited because as a newcomer to needing to implement that feature, other SaaSes like auth0 were complicated and overwhelmed me. Since we have Supabase employees here, one thing that isn't clear to me is if OIDC based SSO is supported, o…
Supabase Auth Engineer here. We initially started off with the SAML 2.0 protocol since it's the one of the oldest protocols and also one that's used by most enterprises. We're definitely looking to add OIDC based SSO support soon so stay tuned!