71–80 of 112 posts
Have been a proud better auth user for the last 6 months! Loved it so far, especially the fact that it's FOSS. Now that it's a venture-funded YC company, I am worried about using it. Should I be?
Does it handle: - Federated sign-in/out? In next-auth, it is a giant pain to implement: https://github.com/nextauthjs/next-auth/discussions/3938 - Automated refreshing of JWT tokens on the client-side? I always end up having to implement my own logic around this. The big problem is if you have multiple API calls going out and they all require JWT auth, you need to check the JWT validity and block the calls until it i…
A better solution might be premade auth primitives (oauth providers, db adapters) that you copy paste into your codebase shadcn-style, and modify when necessary.
I feel like "don't roll your own auth" is less true than it was 5-10 years ago as now there is an abundance of good references and core libraries.
Does it handle: - Federated sign-in/out? In next-auth, it is a giant pain to implement: https://github.com/nextauthjs/next-auth/discussions/3938 - Automated refreshing of JWT tokens on the client-side? I always end up having to implement my own logic around this. The big problem is if you have multiple API calls going out and they all require JWT auth, you need to check the JWT validity and block the calls until it i…
How did you resolve the multiple refresh calls issue? Do you use swr hooks on the front end? Been thinking about how to do this myself.
For all API calls, if the lock is not set, it checks if the JWT is still valid. If it is not, then the lock is set by assigning a new promise to it and saving the resolve call as an external variable to be called after the refresh is done (which resolves the held promise on the other calls, allowing the latest token to be used).
All calls await the lock; it either waits for the refresh to complete or just moves on and performs validation with the currently set token.
Looks like this:
- await on lock; if the lock has been resolved, will just continue on
- Check for JWT validity via exp check (the API server itself would be responsible for checking signature and other validity factors); if not valid, update lock with a new promise and hold the resolver. Perform refresh. Release lock by resolving the promise.
- Use current / refreshed JWT for API call
Does it handle: - Federated sign-in/out? In next-auth, it is a giant pain to implement: https://github.com/nextauthjs/next-auth/discussions/3938 - Automated refreshing of JWT tokens on the client-side? I always end up having to implement my own logic around this. The big problem is if you have multiple API calls going out and they all require JWT auth, you need to check the JWT validity and block the calls until it i…
- Not right now, but there’s already an open issue and a PR in progress. - We don’t use JWTs directly, and sessions always require state (it’s not stateless). And yeah, both the client and server handles automatic session refresh. - Yes, we support both multiple sessions or having different organizations open in different tab: https://www.better-auth.com/docs/plugins/multi-session - Yes, that’s possible, you just nee…
Do people still use X25 these days? I thought everything would have moved to TCP/IP
Tangentially related, but have you thought about a go to market strategy related to AI? I started a new side project with Cursor to see how it goes, and it suggests a lot of packages for a lot of things (often not even suggests, assume you want it and ask you to install already). I imagine there will be a “AIO” AI optimization field soon. Have you considered at all? I mean. If I explicitly ask Cursor models to use Be…
Super happy users :) Agree w/ what everyone has said. For us an extra benefit is the ability to host our user data in our own DB so that we can then dig into it w/ Index. Clerk keeps the data locked in and their "analytics" page is very very limited.
I’m very curious about Better Auth from what I’ve heard so far. I wish I knew about it sooner!