Live data from Hacker News

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

supabase.com

41–50 of 68 posts

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

#41
I’m not currently using supabase but I am using postgrest in a current SSO project, and I ran into major roadblocks with the JWT support. It works fine for versions with symmetric encryption for signing the tokens, where you provide the key to postgrest via config and it uses the key to authenticate requests. However, our identity provider (Azure AD) uses asymmetric encryption for signing tokens, with a public endpoint to retrieve public keys, and postgrest’s support for this is pretty bad. I’ve only been able to work around this issue by serializing the response to a string and providing it as a (really long) config value, and because keys can change over time, I have to restart Postgrest on a daily basis.

For more info, see this issue:

https://github.com/PostgREST/postgrest/issues/1130

Does supabase work around this limitation somehow? How do you get SSO to work for auth providers like Auth0 and AAD that only provide public keys via an endpoint?

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

#42

This project is very impressive! I do hope Supabase decides to support https://github.com/supabase-community/supabase-py , and not just leave it to the community. I would definitely consider becoming a paid customer, assuming Python was supported well/natively. If I am incorrect about Python support, please do let me know.

Supabase Auth Engineer here, also happen to be one of the Python library maintainers. We're looking into a more general approach for "server-side" languages such as Python, Ruby, etc but at the moment the python library is still community supported.

Do you mind sharing more about what you're building and the features of Supabase which would be most important to you?

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

#43

Been doing a lot of Auth related stuff the last day or two so in classic HN style this is very timely for me! One 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…

Would that not be a huge security risk? You could access the SSO credentials of your users that way.

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

#44

I want, want, want to use Supabase - I yearn for a first party SDK for iOS.

We now support Swift: https://supabase.com/docs/reference/swift/introduction We'll double-down on iOS now that we have shipped native Apple logins.

Whaaaaat! I didnt know this, awesome!

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

#45

I think this question deserves a separate thread: Is it possible to see some working examples with some of the big SSO providers, e.g. integrating with Okta, Duo and AD installations in particular (like Azure AD and standard ActiveDirectory) in the documentation? This would go a long way for smaller app developers to get SSO into their apps, even if the examples aren't exhaustive its a starting point. I have found (h…

If you want to see a demo of how to set up SSO, check out the WorkOS Admin Portal. https://workos.com/admin-portal

It's essentially "Stripe Checkout" but for enterprise features like SAML and SCIM. Live demo: https://demo.workos.com/

(I work at WorkOS - sorry if this is hijacking this thread!)

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

#46

I’m not currently using supabase but I am using postgrest in a current SSO project, and I ran into major roadblocks with the JWT support. It works fine for versions with symmetric encryption for signing the tokens, where you provide the key to postgrest via config and it uses the key to authenticate requests. However, our identity provider (Azure AD) uses asymmetric encryption for signing tokens, with a public endpoi…

Supabase Auth engineer here. PostgREST only has "static" asymmetric JWT support. It can't load from `/.well-known/openid-configuration` endpoints. We are tracking this internally to add better UI and support for third-party OIDC.

Most of the OIDC identity providers don't rotate the keys very often, so you can follow the `/.well-known/openid-configuration` endpoint to get the JWKS JSON, and set that as the JWT Secret in the project's dashboard. (It's a bit hacky I know, we're going to be improving the UI on this.)

I know this has been used with Firebase Auth, which is also OIDC compatible with asymmetric JWTs.

EDIT:

> How do you get SSO to work for auth providers like Auth0 and AAD that only provide public keys via an endpoint?

Actually what you're describing is technically not "SSO" but using another Auth system with the rest of the Supabase stack. OIDC support for SSO -- where you use Supabase Auth with Azure AD for example -- is on the roadmap, but only SAML is supported with this announcement today.

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

#47

Been doing a lot of Auth related stuff the last day or two so in classic HN style this is very timely for me! One 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…

Supabase Auth engineer here.

> Question for Supabase: Is it possible to just have a form with username + password and POSTing the login details?

Yes this is how basic email+password sign-in works. No redirects are necessary. For the rest of the flows, some form of redirect is mandatory because that's how the authentication protocols work and we've found it convenient to implement other logins like magic links, email confirmations, etc.

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

#48

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…

Replacing Kong with Deno is a great step (and by simplifying the stack, in line with the elegance I love Supabase for).

- My request with Supabase Logs is that they're easy to format in ways auditors expect (i.e. similar to major tools). That would be a headline benefit, because:

[1] As your customer, I have an easier time with SOC2

[2] In turn, I can pitch that to our enterprise customers: "your compliance will be easier, as your policy and log audits with us will match your other vendors"

I'm going to shoot this to your support channel, but a little more tiny feedback:

- There's no local way for a webhook Edge Function to flag "--no-verify-jwt", which means my local test environment can't be consistent with staging.

- I'm having to use Edge Functions for webhooks despite Postgres Functions being more desirable, because either Kong or PostgREST always requires a JWT. I'm guessing the switch to Deno will make this solvable.

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

#49
post #37

hey 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…

FWIW, the language on your PKCE flow is wrong: * 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 s…

Supabase Auth Engineer here. You are right that a token set is issued and that the authorization server will return an access_token and a refresh_token after validating the code_verifier we chose the term "session" instead of token set as a token (loosely speaking) maps to a server session and we felt that might be easier to understand for our readers who are coming in without an auth background. Sorry for any confusion caused that might have caused.

Thanks for the heads up about replay attacks - we'll be sure to let the Kotlin/Java library developers know about the potential vulnerabilities that you've mentioned.

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

#50
post #32

who actually uses supabase at scale in production?

Specifically for Auth we have linked to a case study at the bottom of this blog post, Parqet, who migrated 125,000 users to Supabase Auth: https://kevcodez.medium.com/migrating-125-000-users-from-aut...

this says nothing about scale. I mean a company who is large(1M +users). This details the complexities of the migration but does not really paint a strong case for using Supabase.
Post reply on HN