(supabase ceo)<p>looks like this is a repost, so I'll copy my comment from last week: <a href="https://news.ycombinator.com/item?id=34834322" rel="nofollow">https://news.ycombinator.com/item?id=34834322</a><p>----<p>this is a great write up. Some responses to your red flags:<p>No setting for session lifetime - as you point out, there is a setting called "JWT expiry limit". I'll mention this to the Auth team and see if they want to consider changing the name of the setting<p>Client-side unencrypted tokens - we give developers options. Serverside auth is definitely more secure, but that's not always an option (eg, on React). If you have a serverside requirement, you can check out our Auth Helpers [0] which give you several patterns for serverside auth.<p>No 2FA on their own platform - we just released this to the Auth server in December[1]. It's on it's way for the platform.<p>This comment caught my eye: "It also creates the ultimate vendor lock-in". That's surprising! You can pg_dump all your entire database, including your users. I can assure you that's easier than other Auth platforms.<p>With that said, I want to let you know that this is all fair feedback. We _definitely_ care about Auth - it's one of our most important products. We have a dedicated Auth team who are fixing issues based on user feedback, as fast as possible. We receive a flood of feedback across a lot of channels, and we do our best to keep up. From an product perspective, we aim to deliver products that makes sense in a Postgres context - you can see that we think deeply about how this service fits with Row Level Security in our MFA post below.<p>Your article has a lot of actionable insights, which I'll go through with the team to continue this improvement.<p>[0] Auth Helpers: <a href="https://supabase.com/docs/guides/auth/auth-helpers">https://supabase.com/docs/guides/auth/auth-helpers</a><p>[1] MFA: <a href="https://supabase.com/blog/mfa-auth-via-rls">https://supabase.com/blog/mfa-auth-via-rls</a>