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

From Supabase to Clerk to Better Auth

blog.val.town

Post reply on HN
Print view View original

141–150 of 259 posts

Re: From Supabase to Clerk to Better Auth

#141

Post by cpard »

tornikeo wrote: post #35

Can someone more intelligent then me tell me why should I offload my postgres users table to some 3rd party provider? Like what is so hard about keeping that table in my VM on hetzner that I have to give it off to someone else? It's not payments, it's just a few fields of data

It feels like a good idea when you are early on in building your product and what matters is quickly iterating on the core features that define your product.

It’s not just the table, it’s also the auth and many other things that you know you will need but you would prefer to focus on other stuff.

Almost always you start by saying that you will replace that when the time comes and you have proved you have a product and now it’s time to actually build the real thing.

Some teams do that and some other, never migrate away and that’s how the GTM of companies like Clerk works.

Re: From Supabase to Clerk to Better Auth

#142

Post by [deleted] »

cyberax wrote: post #110
mooreds wrote: post #102

Earlier quoted context omitted.

> offline auth on mobile Does Better Auth offer this? Or any other auth libraries or solutions? I haven't heard of any, but haven't done an intensive look either. I suppose you could do something with a cached JWT or cached password hash (though sending a password hash to a mobile client spooks me). I'm in the space and interested in learning more.

We ended up caching the credentials and the JWT refresh token from Clerk, and then manually requesting the access token using the Clerk's sparsely documented frontend API. Except that to do this with Clerk, we needed to fake the cache API and then pluck the token out of the undocumented "__clerk_client_jwt" key. This is supported by Better Auth out-of-the box. It doesn't hide these kinds of stuff from you.

[deleted]

Re: From Supabase to Clerk to Better Auth

#143

Post by ClubSandwich7 »

cyberax wrote: post #110
mooreds wrote: post #102

Earlier quoted context omitted.

> offline auth on mobile Does Better Auth offer this? Or any other auth libraries or solutions? I haven't heard of any, but haven't done an intensive look either. I suppose you could do something with a cached JWT or cached password hash (though sending a password hash to a mobile client spooks me). I'm in the space and interested in learning more.

We ended up caching the credentials and the JWT refresh token from Clerk, and then manually requesting the access token using the Clerk's sparsely documented frontend API. Except that to do this with Clerk, we needed to fake the cache API and then pluck the token out of the undocumented "__clerk_client_jwt" key. This is supported by Better Auth out-of-the box. It doesn't hide these kinds of stuff from you.

Hello! I'm a mobile eng @ Clerk. Would you be open to chatting? I'd love to make this experience better for you

Re: From Supabase to Clerk to Better Auth

#144

Post by ctm92 »

tomrod wrote: post #133
jarym wrote: post #65

Earlier quoted context omitted.

"home built auth system" is bound to have "random SSO issues". You fix them, that's how things mature.

Supabase's auth is MIT licensed and OSS, is it not? https://github.com/supabase/auth/blob/master/LICENSE

Supabase is OSS but it's a real pain to actually self host it

Re: From Supabase to Clerk to Better Auth

#145

Post by skrtskrt »

ipnon wrote: post #130
JSR_FDED wrote: post #128

So let me be the one to invite ridicule and scorn by admitting I wrote my own auth code. It was fiddly and boring at the same time. It also wasn’t rocket science, and it works well. I’ll be the first to admit that there are cases where this is a bad idea, I’m just responding to the chants of never roll your own auth. Knowing every single line of code involved allowed me to add some location-based functionality for on…

It’s not that crazy! Or hard. If you can store a hashed password in your users table, and keep the salt secret, you have working auth.

Cookie management and CSRF stuff harder to get right, hashing passwords is completely trivial with and library.

And the cookies are not difficult on a technical level, you just have to spend time understanding the threat models and mapping those models correctly onto your own app.

Re: From Supabase to Clerk to Better Auth

#147

Post by skrtskrt »

wg0 wrote: post #118

Never outsource your auth no matter what unless you're vibe coding and it doesn't matter. If that's the case, don't put auth in at all because it's just you anyway or just use vibe coded password lookups from database at that point. Lastly - here's the law of mother nature: Software funded by VCs will milk you and will milk you dry. Not now, not tomorrow maybe decade or two later when the hot potato being passed arou…

You can literally plug the Better Auth libraries into a little Node server and run it as a separate auth server for free, forever, same as if you used a Django or Rails deployment for that purpose.

That’s all it takes to not use their cloud at all.

Re: From Supabase to Clerk to Better Auth

#148

Post by deaux »

sandeepkd wrote: post #117
impulser_ wrote: post #81

Earlier quoted context omitted.

Majority of apps are B2C apps, they don't need any of this. All you need is Apple and Google Oauth.

If you are just starting out its probably a good idea. Think about the use case when google bans either your app or bans your app user?

Then your business is entirely screwed anyway because you've just lost half the market

At least to me it sounded very much like they were talking about mobile.

Re: From Supabase to Clerk to Better Auth

#150

Post by mooreds »

cyberax wrote: post #110
mooreds wrote: post #102

Earlier quoted context omitted.

> offline auth on mobile Does Better Auth offer this? Or any other auth libraries or solutions? I haven't heard of any, but haven't done an intensive look either. I suppose you could do something with a cached JWT or cached password hash (though sending a password hash to a mobile client spooks me). I'm in the space and interested in learning more.

We ended up caching the credentials and the JWT refresh token from Clerk, and then manually requesting the access token using the Clerk's sparsely documented frontend API. Except that to do this with Clerk, we needed to fake the cache API and then pluck the token out of the undocumented "__clerk_client_jwt" key. This is supported by Better Auth out-of-the box. It doesn't hide these kinds of stuff from you.

Sounds tough. I'd love to learn more.

I wasn't able to find the Better Auth docs about this use case, can you share them here please?

Post reply on HN