[theogravity]

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 is refreshed. In next-auth on the server-side, this is impossible to do since that side is generally stateless, and so you end up with multiple refresh calls happening for the same token.

- The ability to have multiple auth sessions at once, like in a SaaS app where you might belong to multiple accounts / organizations (your intro paragraph sounds like it does)

- Handle how multiple auth sessions are managed if the user happens to open up multiple tabs and swaps accounts in another tab

- Account switching using a Google provider? This seems to be a hard ask for providers like FusionAuth and Cognito. You can't use the Google connector directly but instead use a generic OAuth2 connector where you can specify custom parameters when making the initial OAuth2 flow with Google. The use-case is when a user clicks on the Google sign-in button, it should go to the Google account switcher / selector instead of signing in the user immediately if they have an existing signed-in Google session.

[bekacru]

- 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 need to set the `prompt` parameter to `select_account`

[theogravity]

As another asked, "why?" on no JWT? It makes interfacing with our API servers so much easier as we don't need to maintain infra for sessions and wouldn't be limited by the 4kb limit for sending cookies.

[doshaa]

I use better auth for a real app

There is a plugin provided by better auth for jwt https://www.better-auth.com/docs/plugins/jwt

We dont need it since everything is a single "server" and cookies are good enough. JWT would be added complexity ( e.g sign out ) that i find it better to not be set as a default.

bonus reading http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...

[motorest]

> We don’t use JWTs directly

Why?

[hungryhobbit]

Evidently they prefer to be less secure by default.

[portaouflop]

JWTs aren’t less or more secure by default see the comments posted above

[timpetri]

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.

[theogravity]

No hooks on the FE side. We use a global lock via a promise. Our API clients are not tied to react in any way.

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