Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supabase Auth: SSO, Mobile, and Server-Side Support

supabase.com

Post reply on HN
Print view View original

51–60 of 68 posts

Re: Supabase Auth: SSO, Mobile, and Server-Side Support

#51

Post by BuySomeDip »

andymitchell wrote: post #35
kangmingtay wrote: post #27

Earlier quoted context omitted.

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

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…

I'm struggling to understand your use case here, but here are some thoughts that may be helpful.

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.

Re: Supabase Auth: SSO, Mobile, and Server-Side Support

#52

Post by andymitchell »

BuySomeDip wrote: post #51
andymitchell wrote: post #35

Earlier quoted context omitted.

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…

I'm struggling to understand your use case here, but here are some thoughts that may be helpful. 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…

That is useful to know, thank you.

Alas I envisage this being across many machines.

(I'll edit the previous post for brevity)

Re: Supabase Auth: SSO, Mobile, and Server-Side Support

#55

Post by niklasd »

Great news! Question to the Supabase team: How does Login with Azure (Social login) and SSO (Azure) differ? From my superficial understanding, implementing Login with Azure is enough for logging-in users with Azure AD accounts (and linking their accounts to existing ones).

Re: Supabase Auth: SSO, Mobile, and Server-Side Support

#56

Post by niklasd »

kiwicopple wrote: post #28
andymitchell wrote: post #25

Earlier quoted context omitted.

Thanks Paul, Oso looks great. Re: RLS: Pros - The simplicity+security is hard to beat - Supabase is built around it. I really want the purity of just one platform. Cons (in order) - Our enterprise customers need regular oversight of policy + logs for their compliance (and our ongoing relationship). RLS doesn't expose that afaik. - RLS can't control access to API end points in places like Edge Functions (again, afaik)…

> logs for their compliance Supabase Logs will be fully-integrated with the rest of the supabase stack. Since the Auth JWT flows through the HTTP Authorization header, into PostgREST, then into Postgres, we can pluck the Supabase User ID out of the JWT and store it alongside every log entry. You will be able to reference/join every authorized action in your database to an authenticated user. > RLS can't control acces…

Some additional feedback: In my opinion testing RLS is a problem.

Additionally, I find it hard to keep a good overview over the rules. E.g., in a multi-tenant application one needs to secure every table with a restrictive rule, and it's easy to make a rule permissive, since that is the default & it's not indicated in the Studio UI.

When generating migrations with 'supabase db diff' views are being recreated without 'WITH (security_invoker)' even though they had security_invoker turned on before, leaving your database exposed. Easy to miss, even when you're aware of that.

RLS is just so full of footguns that I find it hard to justify using it in a production system.

(But otherwise I love Supabase! Great job.)

Re: Supabase Auth: SSO, Mobile, and Server-Side Support

#57

Post by mooreds »

Disclosure, I work for FusionAuth, which can both integrate with and compete with Supabase.

Welcome, Supabase, to the world of SAML/SSO. It's a hairy one, but single sign-on is undifferentiated and really great for customers, so I'm glad you joined.

A few thoughts:

* Consider adding identity linking to your roadmap. I noticed[0] that you don't support it, and will create duplicate accounts if someone uses SSO with the same email address that an existing account has. As a model, FusionAuth offers seven linking strategies[1]. This flexibility lets you handle more use cases.

* I'd encourage you (and your customers) to test across as many SPs as you can. SAML is an 800+ page specification and even though we've been offering SAML for over 10 years and have open sourced our bindings[2], we still have edge cases that pop up.

* I'd love to add FusionAuth as a SAML SSO provider to your docs, so will put that on our team's doc roadmap and submit a PR. :)

* Not related to SAML, but I'm glad that you are supporting PKCE. I hope you deprecate the implicit grant; the XSS threat is very real and the OAuth 2.1 spec (still in progress) basically deprecates that grant[3] through omission. Also, we agree that setting cookies (HTTPOnly and secure, please) is a great way to store tokens[4] and that is worth requiring a server side component in applications.

Finally, I understand why this is part of a paid offering; SAML is often used to segment out enterprise customers with $$$. You like to make money, as do we all. But I'd encourage you to think about a free tier because it is so helpful to the user experience. Maybe 1 SAML connection could be part of the base offering?

0: https://supabase.com/docs/guides/platform/sso

1: https://fusionauth.io/docs/v1/tech/identity-providers/#linki...

2: https://github.com/FusionAuth/fusionauth-samlv2/commits/mast...

3: https://oauth.net/2.1/

4: https://fusionauth.io/learn/expert-advice/oauth/oauth-token-...

Re: Supabase Auth: SSO, Mobile, and Server-Side Support

#58

Post by mooreds »

andymitchell wrote: post #16

I can't advocate Supabase enough. Their combo of openness and elegance in their platform leaves me (a developer/entrepreneur) feeling secure. This is perhaps a future topic, but to me it extends out of SSO: Paul (@kiwicopple), do you have an opinion on which enterprise-grade AuthZ provider works best with Supabase? I suspect it's Cerbos or Casbin, but if you ever do it in house (and since you've nailed AuthN that mak…

Here are some other AuthZ as a service providers I've heard of:

* Permit.io: https://www.permit.io/

* Oso: https://www.osohq.com/

And Otterize has an interesting model if you are in the k8s ecosystem: https://otterize.com/

I don't have first hand experience with any of these folks, though I have chatted with some of them.

Re: Supabase Auth: SSO, Mobile, and Server-Side Support

#60

Post by kiwicopple »

niklasd wrote: post #56
kiwicopple wrote: post #28

Earlier quoted context omitted.

> logs for their compliance Supabase Logs will be fully-integrated with the rest of the supabase stack. Since the Auth JWT flows through the HTTP Authorization header, into PostgREST, then into Postgres, we can pluck the Supabase User ID out of the JWT and store it alongside every log entry. You will be able to reference/join every authorized action in your database to an authenticated user. > RLS can't control acces…

Some additional feedback: In my opinion testing RLS is a problem. Additionally, I find it hard to keep a good overview over the rules. E.g., in a multi-tenant application one needs to secure every table with a restrictive rule, and it's easy to make a rule permissive, since that is the default & it's not indicated in the Studio UI. When generating migrations with 'supabase db diff' views are being recreated without '…

we have a lot of work to do for migrations and testing, especially RLS.

for this Launch Week we focused on generating policies (more on that in tomorrows launch week). This is hard for a lot of our audience who aren't familiar with SQL.

In the next few months we'll work on simulating a policy - being able to choose a specific user and see what data would be returned for that user.

We also have `supabase test db`, in case you missed it. It wraps pgTAP and pgProve so that you can write database tests.

> recreated without 'WITH (security_invoker)' even though they had security_invoker turned on before

we use migra for diff'ing. Thanks for raising this - we'll file a bug report asap.

Post reply on HN