this is a great write up. Some responses to your red flags:
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
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.
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.
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.
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.
Your article has a lot of actionable insights, which I'll go through with the team to continue this improvement.
this is a great write up. Some responses to your red flags:
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
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.
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.
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.
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.
Your article has a lot of actionable insights, which I'll go through with the team to continue this improvement.
[0] Auth Helpers: https://supabase.com/docs/guides/auth/auth-helpers
[1] MFA: https://supabase.com/blog/mfa-auth-via-rls