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?
41–50 of 68 posts
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?
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.
Do you mind sharing more about what you're building and the features of Supabase which would be most important to you?
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…
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…
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!)
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…
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.
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…
> 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.
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…
- 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.
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…
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.
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...