[GH-ISSUE #2202] Better Auth support for only external IDPs and no database? #9101

New Issue

GiteaMirror · 2026-04-13T04:25:00-05:00

GiteaMirror commented

2026-04-13 04:25:00 -05:00

Originally created by @liamlows on GitHub (Apr 9, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/2202

Hello,

First I would like to say I am very excited to be trying out better-auth, I really like the package so far and it provides a lot of very cool features out of the box. Also please let me know if this issue needs revision if formatted incorrectly.

That being said I had a question or maybe a feature request regarding setup and how better-auth can be deployed in a Next.JS environment. For our deployment we use Keycloak as our IDP as it is used across many other apps some not being Node based. As such, we were looking for a good authentication framework (that isnt next-auth/auth.js due to bugs we have encountered using it in the past) for our next.js app. We also have various APIs behind the next.js app that we would like to pass the Keycloak JWT to in order to verify authentication and authorization. The next.js server side of the app is seldom used for any actual business logic and acts more as a proxy than anything else.

I noticed that when installing better-auth it requires a database be connected. Is this really necessary if we are not supporting username/password login directly with better-auth? We simply want better-auth to handle the storage and facilitate the use of our JWT issued by keycloak. When running the package without a database i noticed the following warning:

WARN [Better Auth]: No database configuration provided. Using memory adapter in development

Is this warning saying that the memory adapter is still in beta and will soon be a full feature or is it saying that this is just for development of the next.js app and should not be used in production? I was also looking to find information on how better-auth handles refresh token rotation with IDPs such as keycloak, it seems like maybe it already accounts for that behind the scenes?

Maybe our required use case for this is not on the roadmap for better-auth in which case we can try to find an alternative. I could not find this information anywhere though so I figured I'd simply ask directly.

Thanks!

Originally created by @liamlows on GitHub (Apr 9, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/2202 Hello, First I would like to say I am very excited to be trying out better-auth, I really like the package so far and it provides a lot of very cool features out of the box. Also please let me know if this issue needs revision if formatted incorrectly. That being said I had a question or maybe a feature request regarding setup and how better-auth can be deployed in a Next.JS environment. For our deployment we use Keycloak as our IDP as it is used across many other apps some not being Node based. As such, we were looking for a good authentication framework (that isnt next-auth/auth.js due to bugs we have encountered using it in the past) for our next.js app. We also have various APIs behind the next.js app that we would like to pass the Keycloak JWT to in order to verify authentication and authorization. The next.js server side of the app is seldom used for any actual business logic and acts more as a proxy than anything else. I noticed that when installing better-auth it requires a database be connected. Is this really necessary if we are not supporting username/password login directly with better-auth? We simply want better-auth to handle the storage and facilitate the use of our JWT issued by keycloak. When running the package without a database i noticed the following warning: ``` WARN [Better Auth]: No database configuration provided. Using memory adapter in development ``` Is this warning saying that the memory adapter is still in beta and will soon be a full feature or is it saying that this is just for development of the next.js app and should not be used in production? I was also looking to find information on how better-auth handles refresh token rotation with IDPs such as keycloak, it seems like maybe it already accounts for that behind the scenes? Maybe our required use case for this is not on the roadmap for better-auth in which case we can try to find an alternative. I could not find this information anywhere though so I figured I'd simply ask directly. Thanks!

GiteaMirror added the locked label 2026-04-13 04:25:00 -05:00

GiteaMirror closed this issue

2026-04-13 04:25:01 -05:00

GiteaMirror commented

2026-04-13 04:25:04 -05:00

@Bekacru commented on GitHub (Apr 10, 2025):

Better Auth does require a database. The library by itself is a replacement for Keycloak or another IDP as much as it is for next auth. We're not currently planning to support being just an oauth client layer without a database but since this is a frequent request we may consider it.

@Bekacru commented on GitHub (Apr 10, 2025): Better Auth does require a database. The library by itself is a replacement for Keycloak or another IDP as much as it is for next auth. We're not currently planning to support being just an oauth client layer without a database but since this is a frequent request we may consider it.

GiteaMirror commented

2026-04-13 04:25:06 -05:00

@liamlows commented on GitHub (Apr 10, 2025):

Better Auth does require a database. The library by itself is a replacement for Keycloak or another IDP as much as it is for next auth. We're not currently planning to support being just an oauth client layer without a database but since this is a frequent request we may consider it.

Sounds good! I think it would be really cool if this could be a feature of better-auth and could be something toggled in the better-auth constructor or simply assumed if no emailAndPassword attribute is provided. Also, let me know if you'd like me to re-create as a feature request and close this issue or leave this one open as the feature request.

@liamlows commented on GitHub (Apr 10, 2025): > Better Auth does require a database. The library by itself is a replacement for Keycloak or another IDP as much as it is for next auth. We're not currently planning to support being just an oauth client layer without a database but since this is a frequent request we may consider it. Sounds good! I think it would be really cool if this could be a feature of better-auth and could be something toggled in the better-auth constructor or simply assumed if no emailAndPassword attribute is provided. Also, let me know if you'd like me to re-create as a feature request and close this issue or leave this one open as the feature request.

GiteaMirror commented

2026-04-13 04:25:07 -05:00

@coopbri commented on GitHub (Apr 11, 2025):

We had a similar discussion about this here for some more context: discord.com/channels/1288403910284935179/1349320159093067897

Super hopeful to be able to (fully) migrate from Auth.js to Better Auth! Stateless auth is our last battle.

@coopbri commented on GitHub (Apr 11, 2025): We had a similar discussion about this here for some more context: [discord.com/channels/1288403910284935179/1349320159093067897](https://discord.com/channels/1288403910284935179/1349320159093067897) Super hopeful to be able to (fully) migrate from Auth.js to Better Auth! Stateless auth is our last battle.

GiteaMirror commented

2026-04-13 04:25:07 -05:00

@ValentinGurkov commented on GitHub (Apr 28, 2025):

We also have a similar use case and would love to see this

@ValentinGurkov commented on GitHub (Apr 28, 2025): We also have a similar use case and would love to see this

GiteaMirror commented

2026-04-13 04:25:08 -05:00

@lucasahlgrenToxic commented on GitHub (May 5, 2025):

I would also love to see this!

@lucasahlgrenToxic commented on GitHub (May 5, 2025): I would also love to see this!

GiteaMirror commented

2026-04-13 04:25:09 -05:00

@stychu commented on GitHub (May 9, 2025):

We also have a strong interest in Better Auth supporting OIDC-only flows without requiring a dedicated database.
Our use case focuses on the following:

User authentication occurs via an external OIDC provider.
We would like Better Auth to manage the OIDC token and refresh token, storing them securely in cookies.
These cookies would then be used to authenticate subsequent requests from the client to our separate backend APIs.

In this scenario, where Better Auth would primarily act as the OIDC client and manage the session cookies for downstream API consumption, the requirement for a full database instance feels like an unnecessary overhead for our needs.

To offer a potential perspective on implementation, our current system (not using Better Auth) handles a similar flow by:

Storing the OIDC profile information in one cookie after a successful login.
Storing any additional essential user metadata (which we retrieve from our APIs using the OIDC tokens) in a separate cookie. This second cookie effectively serves as a minimal, client-side equivalent to what might otherwise be stored in a small database table.

This approach helps us minimize server-side state for this specific authentication pattern. We believe a similar stateless or "database-light" capability within Better Auth for OIDC flows would be highly beneficial for the broader user base ;)

We are aware that a fully stateless, cookie-based session design like this inherently limits the server's direct ability to actively control individual client session retention compared to database-backed sessions. However, we believe this trade-off can be partially mitigated.

One possible approach to enhance control in such a stateless design could be a "session busting" feature. For instance, BetterAuth could offer an option to associate a version number with the main OIDC session cookie. If an administrator needs to invalidate all current sessions (e.g., due to a security concern or a significant update), they could increment this session version. BetterAuth would then treat any cookie with an older version number as invalid, effectively forcing all users to re-authenticate.

Furthermore, related to managing the client-side state, control over the schema of the metadata stored in the cookie would also be valuable. If the structure of this metadata (e.g., fields, types) is expected to change over time, BetterAuth could potentially incorporate a versioning mechanism for this metadata schema as well. A mismatch between the expected metadata schema version and the version found in a user's cookie could then trigger a re-login or a specific handling flow. This would provide another layer of control and help manage transitions when the data stored on the client side evolves, which we think is a practical consideration for a robust stateless design.

@stychu commented on GitHub (May 9, 2025): We also have a strong interest in Better Auth supporting OIDC-only flows without requiring a dedicated database. Our use case focuses on the following: 1. User authentication occurs via an external OIDC provider. 2. We would like Better Auth to manage the OIDC token and refresh token, storing them securely in cookies. 3. These cookies would then be used to authenticate subsequent requests from the client to our separate backend APIs. In this scenario, where Better Auth would primarily act as the OIDC client and manage the session cookies for downstream API consumption, the requirement for a full database instance feels like an unnecessary overhead for our needs. To offer a potential perspective on implementation, our current system (not using Better Auth) handles a similar flow by: 1. Storing the OIDC profile information in one cookie after a successful login. 2. Storing any additional essential user metadata (which we retrieve from our APIs using the OIDC tokens) in a separate cookie. This second cookie effectively serves as a minimal, client-side equivalent to what might otherwise be stored in a small database table. This approach helps us minimize server-side state for this specific authentication pattern. We believe a similar stateless or "database-light" capability within Better Auth for OIDC flows would be highly beneficial for the broader user base ;) --- We are aware that a fully stateless, cookie-based session design like this inherently limits the server's direct ability to actively control individual client session retention compared to database-backed sessions. However, we believe this trade-off can be partially mitigated. One possible approach to enhance control in such a stateless design could be a "session busting" feature. For instance, BetterAuth could offer an option to associate a version number with the main OIDC session cookie. If an administrator needs to invalidate all current sessions (e.g., due to a security concern or a significant update), they could increment this session version. BetterAuth would then treat any cookie with an older version number as invalid, effectively forcing all users to re-authenticate. Furthermore, related to managing the client-side state, control over the schema of the metadata stored in the cookie would also be valuable. If the structure of this metadata (e.g., fields, types) is expected to change over time, BetterAuth could potentially incorporate a versioning mechanism for this metadata schema as well. A mismatch between the expected metadata schema version and the version found in a user's cookie could then trigger a re-login or a specific handling flow. This would provide another layer of control and help manage transitions when the data stored on the client side evolves, which we think is a practical consideration for a robust stateless design.

GiteaMirror commented

2026-04-13 04:25:10 -05:00

@Tarek-kharsa commented on GitHub (Jun 18, 2025):

We also have a similar use case and would love to see this

@Tarek-kharsa commented on GitHub (Jun 18, 2025): We also have a similar use case and would love to see this

GiteaMirror commented

2026-04-13 04:25:12 -05:00

@Bernardomennndes commented on GitHub (Jun 23, 2025):

We are currently investigating alternatives to Auth.js due to persistent compatibility issues affecting our projects. In parallel, we intend to design a custom authentication package built on top of a more extensible and reliable foundation. Core requirements include cross-subdomain cookie support and seamless integration across five independent applications that consume a shared authentication API and token infrastructure. Better-auth emerges as a strong candidate, the potential to integrate with a decoupled external Identity Provider (IDP) would make better-auth an ideal match for our architectural strategy.

@Bernardomennndes commented on GitHub (Jun 23, 2025): We are currently investigating alternatives to Auth.js due to persistent compatibility issues affecting our projects. In parallel, we intend to design a custom authentication package built on top of a more extensible and reliable foundation. Core requirements include cross-subdomain cookie support and seamless integration across five independent applications that consume a shared authentication API and token infrastructure. Better-auth emerges as a strong candidate, the potential to integrate with a decoupled external Identity Provider (IDP) would make better-auth an ideal match for our architectural strategy.

GiteaMirror commented

2026-04-13 04:25:14 -05:00

@rileyy29 commented on GitHub (Jun 26, 2025):

Similiar use case - would really like to see this as currently it is the only blocker from migrating from Auth.js

@rileyy29 commented on GitHub (Jun 26, 2025): Similiar use case - would really like to see this as currently it is the only blocker from migrating from Auth.js

GiteaMirror commented

2026-04-13 04:25:15 -05:00

@eloraa commented on GitHub (Jun 29, 2025):

Would really like to see this. For now, I have to stick with auth.js, even though I wanted to use better-auth.

@eloraa commented on GitHub (Jun 29, 2025): Would really like to see this. For now, I have to stick with auth.js, even though I wanted to use better-auth.

GiteaMirror commented

2026-04-13 04:25:15 -05:00

@leantrace commented on GitHub (Jul 9, 2025):

+1 for better-auth client only, as we use external IDP

@leantrace commented on GitHub (Jul 9, 2025): +1 for better-auth client only, as we use external IDP

GiteaMirror commented

2026-04-13 04:25:16 -05:00

@douwepausma commented on GitHub (Jul 10, 2025):

Looking for this feature as well. We currently manage our auth with Strapi & Auth.js, and like to use Better Auth with Strapi.

@douwepausma commented on GitHub (Jul 10, 2025): Looking for this feature as well. We currently manage our auth with Strapi & Auth.js, and like to use Better Auth with Strapi.

GiteaMirror commented

2026-04-13 04:25:16 -05:00

@ragecryx commented on GitHub (Jul 10, 2025):

+1 I'd also want that feature

@ragecryx commented on GitHub (Jul 10, 2025): +1 I'd also want that feature

GiteaMirror commented

2026-04-13 04:25:17 -05:00

@pstuerner commented on GitHub (Jul 10, 2025):

+1 i'm getting really frustrated using auth.js and would love to try an alternative, however, i'm working on a company project and keycloak is the only option available. this would be awesome.

@pstuerner commented on GitHub (Jul 10, 2025): +1 i'm getting really frustrated using auth.js and would love to try an alternative, however, i'm working on a company project and keycloak is the only option available. this would be awesome.

GiteaMirror commented

2026-04-13 04:25:17 -05:00

@ragecryx commented on GitHub (Jul 11, 2025):

TBH (and I don't mean it in a harsh way) its very weird requiring direct access to a DB. For me, the way user data are stored or retrieved/matched is almost out of the responsibilities of such library. Few callback-like functions (like, one for creating a user profile, one for matching a profile etc) should be enough for (almost) everyone that needs storage and it should be trivial to implement by them.

@ragecryx commented on GitHub (Jul 11, 2025): TBH (and I don't mean it in a harsh way) its very weird requiring direct access to a DB. For me, the way user data are stored or retrieved/matched is almost out of the responsibilities of such library. Few callback-like functions (like, one for creating a user profile, one for matching a profile etc) should be enough for (almost) everyone that needs storage and it should be trivial to implement by them.

GiteaMirror commented

2026-04-13 04:25:18 -05:00

@stychu commented on GitHub (Jul 11, 2025):

TBH (and I don't mean it in a harsh way) its very weird requiring direct access to a DB. For me, the way user data are stored or retrieved/matched is almost out of the responsibilities of such library. Few callback-like functions (like, one for creating a user profile, one for matching a profile etc) should be enough for (almost) everyone that needs storage and it should be trivial to implement by them.

That would be a perfect world! <3 In that case, betteraouth wouldn't need to be concerned with specific database implementations. Instead, it would provide the respective callbacks for handling user-related actions like creation, matching, and retrieval.

This approach is ideal because it would decouple the library's core authentication logic from the user's data storage layer. Developers could then implement these simple callback functions to connect BetterAuth to any database system they choose, making integration into existing projects trivial. This should definitely be the direction 🎊

@stychu commented on GitHub (Jul 11, 2025): > TBH (and I don't mean it in a harsh way) its very weird requiring direct access to a DB. For me, the way user data are stored or retrieved/matched is almost out of the responsibilities of such library. Few callback-like functions (like, one for creating a user profile, one for matching a profile etc) should be enough for (almost) everyone that needs storage and it should be trivial to implement by them. That would be a perfect world! <3 In that case, `betteraouth` wouldn't need to be concerned with specific database implementations. Instead, it would provide the respective callbacks for handling user-related actions like creation, matching, and retrieval. This approach is ideal because it would decouple the library's core authentication logic from the user's data storage layer. Developers could then implement these simple callback functions to connect `BetterAuth` to any database system they choose, making integration into existing projects trivial. This should definitely be the direction 🎊

GiteaMirror commented

2026-04-13 04:25:19 -05:00

@ggomarighetti commented on GitHub (Jul 13, 2025):

TBH (and I don't mean it in a harsh way) its very weird requiring direct access to a DB. For me, the way user data are stored or retrieved/matched is almost out of the responsibilities of such library. Few callback-like functions (like, one for creating a user profile, one for matching a profile etc) should be enough for (almost) everyone that needs storage and it should be trivial to implement by them.

This reminds me of the Supabase Auth library, that when instantiating it you need to pass it the getAll and setAll methods (if I remember correctly) for cookies. I believe that it responded to a problem of access to these from client/server environments in the different JS frameworks with SSR.

I mention it as to have an example of concrete implementation and example that it is adopted/possible.

@ggomarighetti commented on GitHub (Jul 13, 2025): > TBH (and I don't mean it in a harsh way) its very weird requiring direct access to a DB. For me, the way user data are stored or retrieved/matched is almost out of the responsibilities of such library. Few callback-like functions (like, one for creating a user profile, one for matching a profile etc) should be enough for (almost) everyone that needs storage and it should be trivial to implement by them. This reminds me of the Supabase Auth library, that when instantiating it you need to pass it the getAll and setAll methods (if I remember correctly) for cookies. I believe that it responded to a problem of access to these from client/server environments in the different JS frameworks with SSR. I mention it as to have an example of concrete implementation and example that it is adopted/possible.

GiteaMirror commented

2026-04-13 04:25:20 -05:00

@CanRau commented on GitHub (Jul 14, 2025):

We use kysely as well, but can't comply with the schema requirements, so we'd also really appreciate callbacks/hooks to handle creating, matching, retrieval, etc of users, sessions, etc ourselves as we have a more "complex" schema (for example, possibly multiple emails per user) with multiple tables already in place we'd like to keep, without adding additional (better-auth) tables where not necessary, but would love to join the amazing better-auth community and be able to provide our users with a wider range of auth options 🥰

I saw that this issue has been added to the v1.3 milestone. Does this mean this feature request has been confirmed for development? 🥹

@CanRau commented on GitHub (Jul 14, 2025): We use kysely as well, but can't comply with the schema requirements, so we'd also really appreciate callbacks/hooks to handle creating, matching, retrieval, etc of users, sessions, etc ourselves as we have a more "complex" schema (for example, possibly multiple emails per user) with multiple tables already in place we'd like to keep, without adding additional (better-auth) tables where not necessary, but would love to join the amazing better-auth community and be able to provide our users with a wider range of auth options 🥰 I saw that this issue has been added to the v1.3 milestone. Does this mean this feature request has been confirmed for development? 🥹

GiteaMirror commented

2026-04-13 04:25:21 -05:00

@robertotcestari commented on GitHub (Jul 16, 2025):

Please let us have this! I also have a use case for that!

@robertotcestari commented on GitHub (Jul 16, 2025): Please let us have this! I also have a use case for that!

GiteaMirror commented

2026-04-13 04:25:22 -05:00

@AhmedBaset commented on GitHub (Jul 19, 2025):

This issue was in 1.3.0 milestone. v1.3.0 is out without it

@AhmedBaset commented on GitHub (Jul 19, 2025): This issue was in 1.3.0 milestone. [v1.3.0](https://github.com/better-auth/better-auth/releases/tag/v1.3.0) is out without it

GiteaMirror commented

2026-04-13 04:25:22 -05:00

@arohman84 commented on GitHub (Jul 29, 2025):

please free us from the shackles of authjs

@arohman84 commented on GitHub (Jul 29, 2025): please free us from the shackles of authjs

GiteaMirror commented

2026-04-13 04:25:23 -05:00

@SachinJadeja commented on GitHub (Aug 12, 2025):

This would be an awesome addition, Do it please

@SachinJadeja commented on GitHub (Aug 12, 2025): This would be an awesome addition, Do it please

GiteaMirror commented

2026-04-13 04:25:24 -05:00

@FurkanCodes commented on GitHub (Aug 15, 2025):

Yes! I have been using auth.js for all of my apps but I need an alternative!

@FurkanCodes commented on GitHub (Aug 15, 2025): Yes! I have been using auth.js for all of my apps but I need an alternative!

GiteaMirror commented

2026-04-13 04:25:24 -05:00

@vanducng commented on GitHub (Aug 17, 2025):

+1 with this; in my case, integrating with Keycloak is the only viable option, and the database isn't really necessary.

@vanducng commented on GitHub (Aug 17, 2025): +1 with this; in my case, integrating with Keycloak is the only viable option, and the database isn't really necessary.

GiteaMirror commented

2026-04-13 04:25:25 -05:00

@carlosrodovalho commented on GitHub (Aug 19, 2025):

+1 with this use case. I am so excited to use better auth instead of authjs, and direcovering that this isn't avaliable (yet) was so sad.

@carlosrodovalho commented on GitHub (Aug 19, 2025): +1 with this use case. I am so excited to use better auth instead of authjs, and direcovering that this isn't avaliable (yet) was so sad.

GiteaMirror commented

2026-04-13 04:25:26 -05:00

@HasanBITar commented on GitHub (Aug 19, 2025):

+1 I hope this gets implemented

@HasanBITar commented on GitHub (Aug 19, 2025): +1 I hope this gets implemented

GiteaMirror commented

2026-04-13 04:25:26 -05:00

@productdevbook commented on GitHub (Aug 24, 2025):

How can we prevent this when we only use genericOAuth?

@productdevbook commented on GitHub (Aug 24, 2025): How can we prevent this when we only use genericOAuth?

GiteaMirror commented

2026-04-13 04:25:27 -05:00

@marijngiesen commented on GitHub (Sep 12, 2025):

+1

This would be awesome. We also have a use case for this.

@marijngiesen commented on GitHub (Sep 12, 2025): +1 This would be awesome. We also have a use case for this.

GiteaMirror commented

2026-04-13 04:25:27 -05:00

@alishi973 commented on GitHub (Sep 17, 2025):

Is it possible to use custom adapter to use it without DB and persist data in memory like development? Im not sure if its possible and practical. Im thinking about creating some custom adapter that not using DB.

@alishi973 commented on GitHub (Sep 17, 2025): Is it possible to use custom adapter to use it without DB and persist data in memory like development? Im not sure if its possible and practical. Im thinking about creating some custom adapter that not using DB.

GiteaMirror commented

2026-04-13 04:25:28 -05:00

@muradbu commented on GitHub (Sep 20, 2025):

+1

I'm working on a project where I need to authenticate users in more places than on the web:

Linux machines via key based authentication with PAM
Self-hosted applications via LDAP or OIDC
Web dashboard via magic link and social login

I decided to use Kanidm as IdP because it solves the first two requirements. It falls short on web authentication as there's no OAuth client functionality or authn strategies like magic link. Kanidm maintains its own user database and I'd like to use this as a single source of truth for my user store.

Being able to use Better Auth as a supplementary layer for other IdP providers would be a very useful feature in cases where existing auth infra or legacy systems exist.

I think in my case Better Auth's SSO is interesting for this but it's still experimental. On another note, I'm also evaluating whether I need Kanidm at all since Better Auth covers much more area so I could build LDAP and pubkey auth on top

@muradbu commented on GitHub (Sep 20, 2025): +1 I'm working on a project where I need to authenticate users in more places than on the web: - Linux machines via key based authentication with PAM - Self-hosted applications via LDAP or OIDC - Web dashboard via magic link and social login I decided to use [Kanidm](https://github.com/kanidm/kanidm) as IdP because it solves the first two requirements. It falls short on web authentication as there's no OAuth client functionality or authn strategies like magic link. Kanidm maintains its own user database and I'd like to use this as a single source of truth for my user store. Being able to use Better Auth as a supplementary layer for other IdP providers would be a very useful feature in cases where existing auth infra or legacy systems exist. I think in my case Better Auth's [SSO](https://www.better-auth.com/docs/plugins/sso) is interesting for this but it's still experimental. On another note, I'm also evaluating whether I need Kanidm at all since Better Auth covers much more area so I could build LDAP and pubkey auth on top

GiteaMirror commented

2026-04-13 04:25:28 -05:00

@yordis commented on GitHub (Sep 27, 2025):

@Bekacru now with the auth.js "merger", are you reconsidering the add the functionality? I see you changed the milestone, I wonder if you could share your general thoughts here.

I am using ZITADEL and interested to leverage the package for the cookie session management, ZITADEL token introspection, user, and session management will do the rest

@yordis commented on GitHub (Sep 27, 2025): @Bekacru now with the auth.js "merger", are you reconsidering the add the functionality? I see you changed the milestone, I wonder if you could share your general thoughts here. I am using ZITADEL and interested to leverage the package for the cookie session management, ZITADEL token introspection, user, and session management will do the rest

GiteaMirror commented

2026-04-13 04:25:29 -05:00

@phev8 commented on GitHub (Sep 27, 2025):

Please consider this feature. I was checking out the docs after the auth.js announcement, and saw the need for a database - why? I need a good auth library to manage my users, their sessions etc. in the client. The Next.js app is a proxy to my backend, I don't want to add a database to it. The application already has storage for the user attributes, their tokens, etc. As suggested above, it would be great to be able to customise the storage methods, where I can drop in my API calls instead of using a DB.

@phev8 commented on GitHub (Sep 27, 2025): Please consider this feature. I was checking out the docs after the auth.js announcement, and saw the need for a database - why? I need a good auth library to manage my users, their sessions etc. in the client. The Next.js app is a proxy to my backend, I don't want to add a database to it. The application already has storage for the user attributes, their tokens, etc. As suggested above, it would be great to be able to customise the storage methods, where I can drop in my API calls instead of using a DB.

GiteaMirror commented

2026-04-13 04:25:29 -05:00

@Bekacru commented on GitHub (Sep 27, 2025):

Hey all, we’ll be adding support for stateless auth with no database soon.

The challenge has been figuring out how the many features that currently assume a database like updateUser, a bunch of plugin endpoints and others should behave.

We’re working on some primitives to make this possible without any breaking change. Expect new update from us soon

@Bekacru commented on GitHub (Sep 27, 2025): Hey all, we’ll be adding support for stateless auth with no database soon. The challenge has been figuring out how the many features that currently assume a database like `updateUser`, a bunch of plugin endpoints and others should behave. We’re working on some primitives to make this possible without any breaking change. Expect new update from us soon

GiteaMirror commented

2026-04-13 04:25:30 -05:00

@CanRau commented on GitHub (Sep 29, 2025):

Providing (optional) hooks in the initializer like onUpdateUser etc were you'd provide the plumbing if necessary, right?

@CanRau commented on GitHub (Sep 29, 2025): Providing (optional) hooks in the initializer like `onUpdateUser` etc were you'd provide the plumbing if necessary, right?

GiteaMirror commented

2026-04-13 04:25:30 -05:00

@DrewLandgraveCbsi commented on GitHub (Sep 29, 2025):

@Bekacru This is awesome! We have an internal user registration system that is used across multiple properties and the database requirement was the only thing stopping us from adopting BetterAuth

@DrewLandgraveCbsi commented on GitHub (Sep 29, 2025): @Bekacru This is awesome! We have an internal user registration system that is used across multiple properties and the database requirement was the only thing stopping us from adopting BetterAuth

GiteaMirror commented

2026-04-13 04:25:31 -05:00

@Hassanabdelqader commented on GitHub (Oct 7, 2025):

I would also love to see this!

@Hassanabdelqader commented on GitHub (Oct 7, 2025): I would also love to see this!

GiteaMirror commented

2026-04-13 04:25:32 -05:00

@racosgrove commented on GitHub (Oct 8, 2025):

This describes our own use case exactly. We are upgrading from legacy React Keycloak libraries and I have been trialing Auth.js for months without being satisfied it is production ready. I recently started testing Better Auth and immediately felt it was a step forward, but with the major drawback being no stateless operation as described.

@racosgrove commented on GitHub (Oct 8, 2025): This describes our own use case exactly. We are upgrading from legacy React Keycloak libraries and I have been trialing Auth.js for months without being satisfied it is production ready. I recently started testing Better Auth and immediately felt it was a step forward, but with the major drawback being no stateless operation as described.

GiteaMirror commented

2026-04-13 04:25:32 -05:00

@chiqors commented on GitHub (Oct 8, 2025):

Looking for this integration for keycloak and rbac

@chiqors commented on GitHub (Oct 8, 2025): Looking for this integration for keycloak and rbac

GiteaMirror commented

2026-04-13 04:25:33 -05:00

@cnbrown04 commented on GitHub (Oct 17, 2025):

I think with this integration it would be nice to have a reference table that could be optionally enabled for things like users, obviously sessions and stuff is handled by the IDP but a reference would be nice so you don't have to reference things from the IDP if it's airgapped from other services.

@cnbrown04 commented on GitHub (Oct 17, 2025): I think with this integration it would be nice to have a reference table that could be optionally enabled for things like users, obviously sessions and stuff is handled by the IDP but a reference would be nice so you don't have to reference things from the IDP if it's airgapped from other services.

GiteaMirror commented

2026-04-13 04:25:33 -05:00

@CanRau commented on GitHub (Oct 17, 2025):

I guess with the hooks it's up to you how you want to manage your users, sessions etc.

Really looking forward 🥹

@CanRau commented on GitHub (Oct 17, 2025): I guess with the hooks it's up to you how you want to manage your users, sessions etc. Really looking forward 🥹

GiteaMirror commented

2026-04-13 04:25:34 -05:00

@Sparticuz commented on GitHub (Oct 21, 2025):

Is there a branch we can follow?

@Sparticuz commented on GitHub (Oct 21, 2025): Is there a branch we can follow?

GiteaMirror commented

2026-04-13 04:25:35 -05:00

@cvivieca commented on GitHub (Oct 21, 2025):

Looking forward for this.

@cvivieca commented on GitHub (Oct 21, 2025): Looking forward for this.

GiteaMirror commented

2026-04-13 04:25:36 -05:00

@KraKeN-47 commented on GitHub (Oct 24, 2025):

If refresh token is required at your end, then a database is required for token revocation. Your session can actually act as a refresh token and it's explained here: https://clerk.com/blog/combining-the-benefits-of-session-tokens-and-jwts. A nuance is that you have to disable the session refresh and then the session will act as a refresh token. With this setup you get all the benefits of better-auth session management, admin plugins etc. If you revoke the refresh token (session token) - you successfuly invalidated a users session until the jwt expires. Also, a black list strategy can be extended but short lived jwt's are also fine. @Bekacru @himself65 regarding this setup I've described. Maybe this should be documented or an official plugin can be made (should be pretty straightforward)? Also, my described solution is for JWT auth usecases where the actual IdP is an external service provider.

I have implemented this exact setup for my company integrating with an ecommerce SaaS provider and it works great.
Our usecase is that the SaaS stores ecommerce users, however - we want to control the authentication and authorization flow ourselves + store all the sensitive user data at our side. This requires us to perform a handshake with the SaaS provider and sync their issued JWT's with better-auth issued ones - pretty easy to do when extending better-auth's already inbuilt jwt plugin. Then finally - our token pair includes the session token acting as a refresh token (as I've described above). This setup let's us fully utilize all of better-auth plugins out of the box. Love the package design, best regards to the package creators and maintainers!

@KraKeN-47 commented on GitHub (Oct 24, 2025): If refresh token is required at your end, then a database is required for token revocation. Your session can actually act as a refresh token and it's explained here: https://clerk.com/blog/combining-the-benefits-of-session-tokens-and-jwts. A nuance is that you have to disable the session refresh and then the session will act as a refresh token. With this setup you get all the benefits of better-auth session management, admin plugins etc. If you revoke the refresh token (session token) - you successfuly invalidated a users session until the jwt expires. Also, a black list strategy can be extended but short lived jwt's are also fine. @Bekacru @himself65 regarding this setup I've described. Maybe this should be documented or an official plugin can be made (should be pretty straightforward)? Also, my described solution is for JWT auth usecases where the actual IdP is an external service provider. I have implemented this exact setup for my company integrating with an ecommerce SaaS provider and it works great. Our usecase is that the SaaS stores ecommerce users, however - we want to control the authentication and authorization flow ourselves + store all the sensitive user data at our side. This requires us to perform a handshake with the SaaS provider and sync their issued JWT's with better-auth issued ones - pretty easy to do when extending better-auth's already inbuilt jwt plugin. Then finally - our token pair includes the session token acting as a refresh token (as I've described above). This setup let's us fully utilize all of better-auth plugins out of the box. Love the package design, best regards to the package creators and maintainers!

GiteaMirror commented

2026-04-13 04:25:36 -05:00

@Eveeifyeve commented on GitHub (Oct 26, 2025):

Hey all, we’ll be adding support for stateless auth with no database soon.

The challenge has been figuring out how the many features that currently assume a database like updateUser, a bunch of plugin endpoints and others should behave.

We’re working on some primitives to make this possible without any breaking change. Expect new update from us soon

Let me know if I can help with this.

Eveeifyeve (CEO of DigitalBrewStudios)

@Eveeifyeve commented on GitHub (Oct 26, 2025): > Hey all, we’ll be adding support for stateless auth with no database soon. > > The challenge has been figuring out how the many features that currently assume a database like `updateUser`, a bunch of plugin endpoints and others should behave. > > We’re working on some primitives to make this possible without any breaking change. Expect new update from us soon Let me know if I can help with this. Eveeifyeve (CEO of [DigitalBrewStudios](https://digitalbrewstudios.com))

GiteaMirror commented

2026-04-13 04:25:38 -05:00

@amaryassa commented on GitHub (Oct 26, 2025):

Hey All !

@Bekacru @himself65 Just wondering if any work has started on this issue yet?
I saw it’s part of the 1.4.X milestone but couldn’t find a related PR or branch.
Thanks!

Update : I think this is the PR !
#5601

@amaryassa commented on GitHub (Oct 26, 2025): Hey All ! @Bekacru @himself65 Just wondering if any work has started on this issue yet? I saw it’s part of the 1.4.X milestone but couldn’t find a related PR or branch. Thanks! Update : I think this is the PR ! #5601

GiteaMirror commented

2026-04-13 04:25:38 -05:00

@AhmedBaset commented on GitHub (Oct 26, 2025):

Just wondering if any work has started on this issue yet?

https://github.com/better-auth/better-auth/pull/5470 is a step on the way

@AhmedBaset commented on GitHub (Oct 26, 2025): > Just wondering if any work has started on this issue yet? https://github.com/better-auth/better-auth/pull/5470 is a step on the way

GiteaMirror commented

2026-04-13 04:25:39 -05:00

@Montreal-Dev commented on GitHub (Oct 27, 2025):

Super excited to see stateless auth on the roadmap [1.4.X]!
DB or not, like @Bekacru said :

Gonna make things leaner. Fewer lookups, lower infra costs, no waste. It's going to be challenging but Better Auth can handles this.

Can’t wait to see it make its way over from NextAuth.
❤️ P.S Love y'all

@Montreal-Dev commented on GitHub (Oct 27, 2025): Super excited to see stateless auth on the roadmap [1.4.X]! DB or not, like @Bekacru said : Gonna make things leaner. Fewer lookups, lower infra costs, no waste. It's going to be challenging but Better Auth can handles this. Can’t wait to see it make its way over from NextAuth. ❤️ P.S Love y'all

GiteaMirror commented

2026-04-13 04:25:40 -05:00

@GRA0007 commented on GitHub (Oct 28, 2025):

Not trying to bring down the vibe here, and apologies for contributing to the problem, but could y'all please stop commenting if you're not adding anything meaningful? Things like "looking forward to this feature" or "excited for this" give everyone who is subscribed to this a notification, and I think we'd all only like those when there is meaningful progress on this issue.

If you want to show your support, leave a thumbs up 👍 at the top so maintainers can see how important this is. Commenting is not going to make it happen any faster.

@GRA0007 commented on GitHub (Oct 28, 2025): Not trying to bring down the vibe here, and apologies for contributing to the problem, but could y'all please stop commenting if you're not adding anything meaningful? Things like "looking forward to this feature" or "excited for this" give everyone who is subscribed to this a notification, and I think we'd all only like those when there is meaningful progress on this issue. If you want to show your support, leave a thumbs up 👍 at the top so maintainers can see how important this is. Commenting is not going to make it happen any faster.

GiteaMirror commented

2026-04-13 04:25:41 -05:00

@AhmedBaset commented on GitHub (Oct 29, 2025):

#5470 is a step on the way

Update

Now on canary

cd567659b8/docs/content/docs/concepts/session-management.mdx (L234-L323)

@AhmedBaset commented on GitHub (Oct 29, 2025): > [#5470](https://github.com/better-auth/better-auth/pull/5470) is a step on the way ## Update Now on canary https://github.com/better-auth/better-auth/blob/cd567659b8b6c78bf90843fd7218446a4ca6aa9b/docs/content/docs/concepts/session-management.mdx?plain=1#L234-L323

GiteaMirror commented

2026-04-13 04:25:42 -05:00

@CanRau commented on GitHub (Oct 30, 2025):

Nice just found the canary docs, I mean the .md works, but sometimes I like the context, also the Stateless with Secondary Storage looks exactly like what I'm after 😍

@CanRau commented on GitHub (Oct 30, 2025): Nice just found the canary docs, I mean the .md works, but sometimes I like the context, also the [Stateless with Secondary Storage](https://canary.better-auth.com/docs/concepts/session-management#stateless-with-secondary-storage) looks exactly like what I'm after 😍

GiteaMirror commented

2026-04-13 04:25:43 -05:00

@better-auth-agent[bot] commented on GitHub (Oct 30, 2025):

Better Auth currently expects a database connection for storing sessions and other data—even if you’re only using an external identity provider like Keycloak. When you see the warning about “using memory adapter in development,” that means if no database is configured, the package falls back to an in‑memory adapter which is intended solely for development and testing purposes. It isn’t recommended for production use.

If your goal is to have a stateless setup with external JWTs and minimal database involvement, you might want to check out the stateless mode with secondary storage as described in the canary documentation. This mode is designed for scenarios like yours where Next.js mostly acts as a proxy and user credentials aren’t managed internally.

Regarding refresh token rotation with external providers such as Keycloak, Better Auth does have mechanisms for token management. However, it isn’t always explicitly clear from the documentation if these rotate fully “behind the scenes” when you’re using an external system. You might need to verify your particular configuration to ensure that refresh tokens are handled as expected.

Next steps:

In production, replace the memory adapter with a proper database (or consider the stateless mode with secondary storage from the canary docs) to securely store session data.
Double‑check your Keycloak integration and token management configuration to confirm that refresh token rotation works as you require.
Test your implementation under production‑like conditions to ensure that tokens aren’t prematurely expiring.

This should get you on the right track for deploying Better Auth in a Next.js environment using an external IDP. If you need further clarification, reviewing the canary documentation on stateless session management may provide additional insights [1], [2].

Diagram • Discord • GitHub

@better-auth-agent[bot] commented on GitHub (Oct 30, 2025): Better Auth currently expects a database connection for storing sessions and other data—even if you’re only using an external identity provider like Keycloak. When you see the warning about “using memory adapter in development,” that means if no database is configured, the package falls back to an in‑memory adapter which is intended solely for development and testing purposes. It isn’t recommended for production use. If your goal is to have a stateless setup with external JWTs and minimal database involvement, you might want to check out the stateless mode with secondary storage as described in the canary documentation. This mode is designed for scenarios like yours where Next.js mostly acts as a proxy and user credentials aren’t managed internally. Regarding refresh token rotation with external providers such as Keycloak, Better Auth does have mechanisms for token management. However, it isn’t always explicitly clear from the documentation if these rotate fully “behind the scenes” when you’re using an external system. You might need to verify your particular configuration to ensure that refresh tokens are handled as expected. Next steps: 1. In production, replace the memory adapter with a proper database (or consider the stateless mode with secondary storage from the canary docs) to securely store session data. 2. Double‑check your Keycloak integration and token management configuration to confirm that refresh token rotation works as you require. 3. Test your implementation under production‑like conditions to ensure that tokens aren’t prematurely expiring. This should get you on the right track for deploying Better Auth in a Next.js environment using an external IDP. If you need further clarification, reviewing the canary documentation on stateless session management may provide additional insights [[1]](https://github.com/better-auth/better-auth/issues/2202), [[2]](https://github.com/better-auth/better-auth/issues/4978).  [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)

GiteaMirror commented

2026-04-13 04:25:43 -05:00

@RicardoAvans commented on GitHub (Oct 31, 2025):

Does anyone here know how to get the accessToken when using the stateless mode of better-auth? I saw there is a getAccessToken method but that requires an accountID which I don't know where to get from. I'm using social sign in together with better-auth so I don't want to store users inside a database.

@RicardoAvans commented on GitHub (Oct 31, 2025): Does anyone here know how to get the accessToken when using the stateless mode of better-auth? I saw there is a getAccessToken method but that requires an accountID which I don't know where to get from. I'm using social sign in together with better-auth so I don't want to store users inside a database.

GiteaMirror commented

2026-04-13 04:25:44 -05:00

@better-auth-agent[bot] commented on GitHub (Oct 31, 2025):

Based on the issue described, here are the key points and next steps:

• The memory adapter that’s automatically used when no database configuration is provided is intended only for development. In production, Better Auth expects a persistent database connection to reliably store user sessions, account details, and token information. This is why you see the warning – it isn’t indicating that the memory adapter is nearing full production support; rather, it’s alerting you that you’re running in a development mode without persistent storage [1].

• When using an external IDP (Keycloak) and relying solely on its JWT without managing a local user store, you lose the default mechanism Better Auth uses to track users. In production, the framework requires an accountID (or equivalent user identifier) to retrieve tokens via methods like getAccessToken. Without a stored user record (i.e., when running entirely stateless), there is no accountID to reference, and so the getAccessToken method cannot function as expected [2].

• Regarding refresh token rotation: Better Auth’s built-in flows for refresh token handling are designed for scenarios where Better Auth manages user records. If you’re delegating the entire authentication flow to Keycloak and not storing users, the built-in refresh behavior may not automatically apply. You would need to either (a) implement a custom callback during sign-in to capture and relay the JWT and refresh token data, or (b) consider a minimal persistent storage option (even if just to store tokens and essential user IDs) so that you can leverage the full Better Auth functionality for token rotation, sessions, and downstream API calls [2].

Next steps/troubleshooting recommendations:

For a production-ready setup, consider using at least a minimal database (or supported persistent store) to track essential user information (including an accountID) even if you’re only using external IDPs. This will allow Better Auth’s token retrieval and refresh flows to work as intended.
If you prefer to avoid any database completely, you’ll need to customize the authentication flow. Use Better Auth’s callbacks or custom plugins to extract and temporarily store the access token as part of the JWT payload or in a secure cookie. This approach, however, means you’re responsible for managing token lifecycles and secure storage, and it deviates from the default Better Auth pattern.
Evaluate your requirements around refresh token rotation. If your setup depends on that feature, the current stateless (in-memory) approach may not meet your production needs, and the minimal persistent storage route might be preferable.

In summary, the memory adapter warning means that the adapter is only for development, and using Better Auth in a completely stateless (no-database) mode means you won’t have a reliable way of accessing the access token (or performing token rotation) because there’s no stored user entry and accountID for reference. Customizing your flow or adding a minimal persistent backend would be the recommended way forward [1], [2].

Please let me know if you have any questions or need further clarification.

Diagram • Discord • GitHub

@better-auth-agent[bot] commented on GitHub (Oct 31, 2025): Based on the issue described, here are the key points and next steps: • The memory adapter that’s automatically used when no database configuration is provided is intended only for development. In production, Better Auth expects a persistent database connection to reliably store user sessions, account details, and token information. This is why you see the warning – it isn’t indicating that the memory adapter is nearing full production support; rather, it’s alerting you that you’re running in a development mode without persistent storage [[1]](https://github.com/better-auth/better-auth/issues/2202). • When using an external IDP (Keycloak) and relying solely on its JWT without managing a local user store, you lose the default mechanism Better Auth uses to track users. In production, the framework requires an accountID (or equivalent user identifier) to retrieve tokens via methods like getAccessToken. Without a stored user record (i.e., when running entirely stateless), there is no accountID to reference, and so the getAccessToken method cannot function as expected [[2]](https://github.com/better-auth/better-auth/issues/4978). • Regarding refresh token rotation: Better Auth’s built-in flows for refresh token handling are designed for scenarios where Better Auth manages user records. If you’re delegating the entire authentication flow to Keycloak and not storing users, the built-in refresh behavior may not automatically apply. You would need to either (a) implement a custom callback during sign-in to capture and relay the JWT and refresh token data, or (b) consider a minimal persistent storage option (even if just to store tokens and essential user IDs) so that you can leverage the full Better Auth functionality for token rotation, sessions, and downstream API calls [[2]](https://github.com/better-auth/better-auth/issues/4978). Next steps/troubleshooting recommendations: 1. For a production-ready setup, consider using at least a minimal database (or supported persistent store) to track essential user information (including an accountID) even if you’re only using external IDPs. This will allow Better Auth’s token retrieval and refresh flows to work as intended. 2. If you prefer to avoid any database completely, you’ll need to customize the authentication flow. Use Better Auth’s callbacks or custom plugins to extract and temporarily store the access token as part of the JWT payload or in a secure cookie. This approach, however, means you’re responsible for managing token lifecycles and secure storage, and it deviates from the default Better Auth pattern. 3. Evaluate your requirements around refresh token rotation. If your setup depends on that feature, the current stateless (in-memory) approach may not meet your production needs, and the minimal persistent storage route might be preferable. In summary, the memory adapter warning means that the adapter is only for development, and using Better Auth in a completely stateless (no-database) mode means you won’t have a reliable way of accessing the access token (or performing token rotation) because there’s no stored user entry and accountID for reference. Customizing your flow or adding a minimal persistent backend would be the recommended way forward [[1]](https://github.com/better-auth/better-auth/issues/2202), [[2]](https://github.com/better-auth/better-auth/issues/4978). Please let me know if you have any questions or need further clarification.  [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)

GiteaMirror commented

2026-04-13 04:25:45 -05:00

@vonazt commented on GitHub (Oct 31, 2025):

Does anyone here know how to get the accessToken when using the stateless mode of better-auth? I saw there is a getAccessToken method but that requires an accountID which I don't know where to get from. I'm using social sign in together with better-auth so I don't want to store users inside a database.

Also need this - using better-auth with NextJS as a proxy for an API, and using Keycloak as an IDP, so still need to get the access token.

@vonazt commented on GitHub (Oct 31, 2025): > Does anyone here know how to get the accessToken when using the stateless mode of better-auth? I saw there is a getAccessToken method but that requires an accountID which I don't know where to get from. I'm using social sign in together with better-auth so I don't want to store users inside a database. Also need this - using `better-auth` with NextJS as a proxy for an API, and using Keycloak as an IDP, so still need to get the access token.

GiteaMirror commented

2026-04-13 04:25:45 -05:00

@better-auth-agent[bot] commented on GitHub (Oct 31, 2025):

Better Auth currently expects a database connection to persist user and session data—even if you're only using an external IDP like Keycloak. The warning you saw indicates that when no database is provided, it falls back to a memory adapter meant solely for development, not for production use. In production, the memory adapter isn’t fully supported.

Regarding access tokens, the getAccessToken method expects an account ID because Better Auth’s design assumes that user data (even if minimal) is stored during the authentication handshake. In a stateless flow (such as solely delegating login to an external backend), you need some mechanism to map the external user (and their tokens) to an internal record. Without any user record in a database, there isn’t a straightforward way to retrieve the access token because that process is tied to the stored session and account information.

In short, for your Next.js proxy setup using Keycloak:
• If you want to use Better Auth’s built‐in session and token management (including refresh token rotation), you’ll need to provide a database adapter, even if it simply stores minimal user records.
• The memory adapter is intended for development only—not as a production solution.
• If you’d prefer not to store users at all, you may need to either develop a custom adapter or reconsider using Better Auth, as its design currently assumes an internal storage layer.

If a truly stateless mode (with no database dependency and full support for external IDPs) is critical for your architecture, you might want to file a feature request or explore another solution until that capability is natively supported. This approach would allow you to delegate login logic to your backend while handling token management separately.

I hope this clarifies the next steps. Please let me know if you have any further questions or need additional troubleshooting details [1][2][3].

Diagram • Discord • GitHub

@better-auth-agent[bot] commented on GitHub (Oct 31, 2025): Better Auth currently expects a database connection to persist user and session data—even if you're only using an external IDP like Keycloak. The warning you saw indicates that when no database is provided, it falls back to a memory adapter meant solely for development, not for production use. In production, the memory adapter isn’t fully supported. Regarding access tokens, the getAccessToken method expects an account ID because Better Auth’s design assumes that user data (even if minimal) is stored during the authentication handshake. In a stateless flow (such as solely delegating login to an external backend), you need some mechanism to map the external user (and their tokens) to an internal record. Without any user record in a database, there isn’t a straightforward way to retrieve the access token because that process is tied to the stored session and account information. In short, for your Next.js proxy setup using Keycloak: • If you want to use Better Auth’s built‐in session and token management (including refresh token rotation), you’ll need to provide a database adapter, even if it simply stores minimal user records. • The memory adapter is intended for development only—not as a production solution. • If you’d prefer not to store users at all, you may need to either develop a custom adapter or reconsider using Better Auth, as its design currently assumes an internal storage layer. If a truly stateless mode (with no database dependency and full support for external IDPs) is critical for your architecture, you might want to file a feature request or explore another solution until that capability is natively supported. This approach would allow you to delegate login logic to your backend while handling token management separately. I hope this clarifies the next steps. Please let me know if you have any further questions or need additional troubleshooting details [[1]](https://github.com/better-auth/better-auth/issues/2202)[[2]](https://github.com/better-auth/better-auth/issues/4978)[[3]](https://github.com/better-auth/better-auth/issues/1559).  [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)

GiteaMirror commented

2026-04-13 04:25:46 -05:00

@leantrace commented on GitHub (Oct 31, 2025):

I came here to realize that Better Auth currently doesn’t support using an external backend as an auth provider.
I’m running Auth.js (next-auth@5.0.0-beta.29), which works perfectly fine with an external IdP.

Since the Better Auth team recently announced they’ll be taking over Auth.js, I was considering migrating, but this limitation is a blocker for now.
I hope supporting external identity providers will become a higher priority soon!

@leantrace commented on GitHub (Oct 31, 2025): I came here to realize that Better Auth currently doesn’t support using an external backend as an auth provider. I’m running Auth.js (next-auth@5.0.0-beta.29), which works perfectly fine with an external IdP. Since the Better Auth team recently announced they’ll be taking over Auth.js, I was considering migrating, but this limitation is a blocker for now. I hope supporting external identity providers will become a higher priority soon!

GiteaMirror commented

2026-04-13 04:25:47 -05:00

@better-auth-agent[bot] commented on GitHub (Oct 31, 2025):

Better Auth currently requires a database connection for production use—even if you’re only handling external IDPs like Keycloak. When no database is provided, the package falls back to an in-memory adapter that is intended solely for development, and using it in production is not recommended [1]. In addition, while some basic JWT handling is available, there isn’t full support for delegating all login logic to an external auth backend (as Auth.js does) or for managing refresh token rotation entirely behind the scenes for external providers [2].

Next steps:
• If you plan to handle production traffic using external IDPs only, consider implementing a minimal database for session storage or wait for future releases that may offer a stateless mode.
• Submit or follow a feature request for external-auth-only support and enhanced refresh token rotation with providers like Keycloak.
• In the meantime, if not wanting to maintain a database is critical for your use case, you may want to explore alternatives like Auth.js, which already support this workflow [3].

Please note that these limitations are current and the Better Auth team is working on improvements, so checking the roadmap updates periodically would be a good idea.

Diagram • Discord • GitHub

@better-auth-agent[bot] commented on GitHub (Oct 31, 2025): Better Auth currently requires a database connection for production use—even if you’re only handling external IDPs like Keycloak. When no database is provided, the package falls back to an in-memory adapter that is intended solely for development, and using it in production is not recommended [[1]](https://github.com/better-auth/better-auth/issues/2202). In addition, while some basic JWT handling is available, there isn’t full support for delegating all login logic to an external auth backend (as Auth.js does) or for managing refresh token rotation entirely behind the scenes for external providers [[2]](https://github.com/better-auth/better-auth/issues/4978). Next steps: • If you plan to handle production traffic using external IDPs only, consider implementing a minimal database for session storage or wait for future releases that may offer a stateless mode. • Submit or follow a feature request for external-auth-only support and enhanced refresh token rotation with providers like Keycloak. • In the meantime, if not wanting to maintain a database is critical for your use case, you may want to explore alternatives like Auth.js, which already support this workflow [[3]](https://github.com/better-auth/better-auth/issues/1559). Please note that these limitations are current and the Better Auth team is working on improvements, so checking the roadmap updates periodically would be a good idea.  [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)

GiteaMirror commented

2026-04-13 04:25:47 -05:00

@jaredmcqueen commented on GitHub (Nov 12, 2025):

fyi saw this:
https://canary.better-auth.com/docs/concepts/session-management#stateless-session-management

seems like 1.4 beta supports database-less deployments

pnpm i better-auth@beta

@jaredmcqueen commented on GitHub (Nov 12, 2025): fyi saw this: https://canary.better-auth.com/docs/concepts/session-management#stateless-session-management seems like 1.4 beta supports database-less deployments `pnpm i better-auth@beta`

GiteaMirror commented

2026-04-13 04:25:47 -05:00

@TimFL commented on GitHub (Nov 12, 2025):

fyi saw this:
https://canary.better-auth.com/docs/concepts/session-management#stateless-session-management

seems like 1.4 beta supports database-less deployments

pnpm i better-auth@beta

I'm a bit confused by how the refreshCache strategy works. The default is database lookup (what db? in memory) and the other options are unclear if refreshing means calling a an e.g. third party IdP to get a new access token, for example... or is it never ever again verifying tokens and just keeps resigning what's in the cookie store?

Imo the documentation is still lacking, would need to do a deep dive into the respective PRs to check source code changes to fully understand how this works.

//EDIT: Just skimmed through the source looking for refreshCache traces and from what I could see, it's really just updating the expires at portion of the cookie, no external validation whether something is still valid. Is there a way to tie this into e.g. OIDC on primary auth server and generic oauth on secondary, where stateless mode still enforces refresh token checks for updated access tokens? That'd be the best of both worlds, having no DB backing your secondary auth setups (e.g. apps on subdomains etc.) but the generic oauth flow is still honored by refreshing your authentication data when your session is about to expire.

@TimFL commented on GitHub (Nov 12, 2025): > fyi saw this: > https://canary.better-auth.com/docs/concepts/session-management#stateless-session-management > > seems like 1.4 beta supports database-less deployments > > `pnpm i better-auth@beta` I'm a bit confused by how the refreshCache strategy works. The default is database lookup (what db? in memory) and the other options are unclear if refreshing means calling a an e.g. third party IdP to get a new access token, for example... or is it never ever again verifying tokens and just keeps resigning what's in the cookie store? Imo the documentation is still lacking, would need to do a deep dive into the respective PRs to check source code changes to fully understand how this works. //EDIT: Just skimmed through the source looking for refreshCache traces and from what I could see, it's really just updating the expires at portion of the cookie, no external validation whether something is still valid. Is there a way to tie this into e.g. OIDC on primary auth server and generic oauth on secondary, where stateless mode still enforces refresh token checks for updated access tokens? That'd be the best of both worlds, having no DB backing your secondary auth setups (e.g. apps on subdomains etc.) but the generic oauth flow is still honored by refreshing your authentication data when your session is about to expire.

GiteaMirror commented

2026-04-13 04:25:48 -05:00

@realtebo commented on GitHub (Nov 13, 2025):

We are using latest beta and can confirm stateless is working without problems.
Add a cent: it's working on aws amplify, that is something like a battle arena for js

Whern 1.4 will be released we will switch to stable.
actually we're in prod with beta versione due to hurry up to kick off the train the next-auth

@realtebo commented on GitHub (Nov 13, 2025): We are using latest beta and can confirm stateless is working without problems. Add a cent: it's working on aws amplify, that is something like a battle arena for js Whern 1.4 will be released we will switch to stable. actually we're in prod with beta versione due to hurry up to kick off the train the next-auth

GiteaMirror commented

2026-04-13 04:25:49 -05:00

@iRajatDas commented on GitHub (Nov 13, 2025):

We are using latest beta and can confirm stateless is working without problems. Add a cent: it's working on aws amplify, that is something like a battle arena for js

Whern 1.4 will be released we will switch to stable. actually we're in prod with beta versione due to hurry up to kick off the train the next-auth

Hey, could you please share the working starter project?

@iRajatDas commented on GitHub (Nov 13, 2025): > We are using latest beta and can confirm stateless is working without problems. Add a cent: it's working on aws amplify, that is something like a battle arena for js > > Whern 1.4 will be released we will switch to stable. actually we're in prod with beta versione due to hurry up to kick off the train the next-auth Hey, could you please share the working starter project?

GiteaMirror commented

2026-04-13 04:25:49 -05:00

@marungbukid commented on GitHub (Nov 13, 2025):

getAccessToken doesn't work on the stateless mode

@marungbukid commented on GitHub (Nov 13, 2025): `getAccessToken` doesn't work on the stateless mode

GiteaMirror commented

2026-04-13 04:25:49 -05:00

@devhmac commented on GitHub (Nov 13, 2025):

fyi saw this:
https://canary.better-auth.com/docs/concepts/session-management#stateless-session-management
seems like 1.4 beta supports database-less deployments
pnpm i better-auth@beta

I'm a bit confused by how the refreshCache strategy works. The default is database lookup (what db? in memory) and the other options are unclear if refreshing means calling a an e.g. third party IdP to get a new access token, for example... or is it never ever again verifying tokens and just keeps resigning what's in the cookie store?

Imo the documentation is still lacking, would need to do a deep dive into the respective PRs to check source code changes to fully understand how this works.

//EDIT: Just skimmed through the source looking for refreshCache traces and from what I could see, it's really just updating the expires at portion of the cookie, no external validation whether something is still valid. Is there a way to tie this into e.g. OIDC on primary auth server and generic oauth on secondary, where stateless mode still enforces refresh token checks for updated access tokens? That'd be the best of both worlds, having no DB backing your secondary auth setups (e.g. apps on subdomains etc.) but the generic oauth flow is still honored by refreshing your authentication data when your session is about to expire.

marungbukid

getAccessToken doesn't work on the stateless mode

Also interested to understand what the plan for these two parts going forward is. I have this Beta implemented in our project, and while it totally works for initial login, in struggling a bit to understand:

Intended access to the accessToken as needed as a an auth header header for authenticated requests - given getAccessToken doesnt work (Assuming this is because its not being stored anywhere associated with the cookie session id by default) - Is the intention to then just set it as part of custom session in http only cookies? or just manage storage yourself?
Im utilizing genericOAuth to configure this against my IDP, and as the above commenter calls out theres no real references at all to any refresh/validation strategy - and want to know where that fits

Totally respect this is all just in beta, and was just put out, but would be helpful to know plan to evaluate if this is something we're going to be able to utilize at scale

@devhmac commented on GitHub (Nov 13, 2025): > > fyi saw this: > > https://canary.better-auth.com/docs/concepts/session-management#stateless-session-management > > seems like 1.4 beta supports database-less deployments > > `pnpm i better-auth@beta` > > I'm a bit confused by how the refreshCache strategy works. The default is database lookup (what db? in memory) and the other options are unclear if refreshing means calling a an e.g. third party IdP to get a new access token, for example... or is it never ever again verifying tokens and just keeps resigning what's in the cookie store? > > Imo the documentation is still lacking, would need to do a deep dive into the respective PRs to check source code changes to fully understand how this works. > > //EDIT: Just skimmed through the source looking for refreshCache traces and from what I could see, it's really just updating the expires at portion of the cookie, no external validation whether something is still valid. Is there a way to tie this into e.g. OIDC on primary auth server and generic oauth on secondary, where stateless mode still enforces refresh token checks for updated access tokens? That'd be the best of both worlds, having no DB backing your secondary auth setups (e.g. apps on subdomains etc.) but the generic oauth flow is still honored by refreshing your authentication data when your session is about to expire. [marungbukid](https://github.com/marungbukid) > `getAccessToken` doesn't work on the stateless mode Also interested to understand what the plan for these two parts going forward is. I have this Beta implemented in our project, and while it totally works for initial login, in struggling a bit to understand: 1. Intended access to the `accessToken` as needed as a an auth header header for authenticated requests - given `getAccessToken` doesnt work (Assuming this is because its not being stored anywhere associated with the cookie session id by default) - Is the intention to then just set it as part of custom session in http only cookies? or just manage storage yourself? 2. Im utilizing `genericOAuth` to configure this against my IDP, and as the above commenter calls out theres no real references at all to any refresh/validation strategy - and want to know where that fits Totally respect this is all just in beta, and was _just_ put out, but would be helpful to know plan to evaluate if this is something we're going to be able to utilize at scale

GiteaMirror commented

2026-04-13 04:25:51 -05:00

@CanRau commented on GitHub (Nov 18, 2025):

From Discord:
Hey, as stateless has finally shipped in canary, I'm finally trying to integrate better auth into a project, for compatibility reasons I want to start with the emailOTP plugin but am not yet completely sure as to how to properly make it work with Stateless with Secondary Storage. There's currently not a direct option to store and verify the otp manually in my own backend, right? I think one option currently could be using storeOTP with custom encryptor setting I guess right? Or is there a better way?
[..]
storeOTP doesn't seem to be the right place, at least for verification as decrypt doesn't get called, maybe it'd be nice to be able to override checkVerificationOTP, but maybe I can work around this using hooks, tho not yet sure how

Also considered a custom db adapter, as I basically just need to make it work with our schema 🤓 maybe that'd be the "best" option in our case? 🤔

@CanRau commented on GitHub (Nov 18, 2025): From [Discord](https://discord.com/channels/1288403910284935179/1288408077040619566/1433480375610638506): Hey, as stateless has finally shipped in canary, I'm finally trying to integrate better auth into a project, for compatibility reasons I want to start with the emailOTP plugin but am not yet completely sure as to how to properly make it work with [Stateless with Secondary Storage](https://canary.better-auth.com/docs/concepts/session-management#stateless-with-secondary-storage). There's currently not a direct option to store and verify the otp manually in my own backend, right? I think one option currently could be using storeOTP with [custom encryptor](https://canary.better-auth.com/docs/plugins/email-otp#:~:text=in%20your%20database.-,Custom%20encryptor,-auth.ts) setting I guess right? Or is there a better way? [..] storeOTP doesn't seem to be the right place, at least for verification as decrypt doesn't get called, maybe it'd be nice to be able to override [checkVerificationOTP](https://github.com/better-auth/better-auth/blob/7b65ddd02c3d6fbd328859516ed3e72c2ca02392/packages/better-auth/src/plugins/email-otp/index.ts#L468C4-L468C24), but maybe I can work around this using hooks, tho not yet sure how Also considered a custom db adapter, as I basically just need to make it work with our schema 🤓 maybe that'd be the "best" option in our case? 🤔

GiteaMirror commented

2026-04-13 04:25:52 -05:00

@TimFL commented on GitHub (Nov 19, 2025):

From Discord: Hey, as stateless has finally shipped in canary, I'm finally trying to integrate better auth into a project, for compatibility reasons I want to start with the emailOTP plugin but am not yet completely sure as to how to properly make it work with Stateless with Secondary Storage. There's currently not a direct option to store and verify the otp manually in my own backend, right? I think one option currently could be using storeOTP with custom encryptor setting I guess right? Or is there a better way? [..] storeOTP doesn't seem to be the right place, at least for verification as decrypt doesn't get called, maybe it'd be nice to be able to override checkVerificationOTP, but maybe I can work around this using hooks, tho not yet sure how

Also considered a custom db adapter, as I basically just need to make it work with our schema 🤓 maybe that'd be the "best" option in our case? 🤔

I think there is a misunderstanding what stateless is supposed to achieve. It's supposed to be a client that consumes an external IdP / Auth server and does not manage auth on it's own (other than the active session in memory). EmailOTP is supposed to be on your IdP / Auth server (and your stateless better-auth setup just consumes that OIDC / OAuth server via the generic Oauth plugin for authentication).

I don't think it makes sense to integrate any plugin with a stateless auth setup (since it's supposed to tie into an external auth server that can have any number of authentication ways / plugins attached, your app needs to know nothing about them).

@TimFL commented on GitHub (Nov 19, 2025): > From [Discord](https://discord.com/channels/1288403910284935179/1288408077040619566/1433480375610638506): Hey, as stateless has finally shipped in canary, I'm finally trying to integrate better auth into a project, for compatibility reasons I want to start with the emailOTP plugin but am not yet completely sure as to how to properly make it work with [Stateless with Secondary Storage](https://canary.better-auth.com/docs/concepts/session-management#stateless-with-secondary-storage). There's currently not a direct option to store and verify the otp manually in my own backend, right? I think one option currently could be using storeOTP with [custom encryptor](https://canary.better-auth.com/docs/plugins/email-otp#:~:text=in%20your%20database.-,Custom%20encryptor,-auth.ts) setting I guess right? Or is there a better way? [..] storeOTP doesn't seem to be the right place, at least for verification as decrypt doesn't get called, maybe it'd be nice to be able to override [checkVerificationOTP](https://github.com/better-auth/better-auth/blob/7b65ddd02c3d6fbd328859516ed3e72c2ca02392/packages/better-auth/src/plugins/email-otp/index.ts#L468C4-L468C24), but maybe I can work around this using hooks, tho not yet sure how > > Also considered a custom db adapter, as I basically just need to make it work with our schema 🤓 maybe that'd be the "best" option in our case? 🤔 I think there is a misunderstanding what stateless is supposed to achieve. It's supposed to be a client that consumes an external IdP / Auth server and does not manage auth on it's own (other than the active session in memory). EmailOTP is supposed to be on your IdP / Auth server (and your stateless better-auth setup just consumes that OIDC / OAuth server via the generic Oauth plugin for authentication). I don't think it makes sense to integrate any plugin with a stateless auth setup (since it's supposed to tie into an external auth server that can have any number of authentication ways / plugins attached, your app needs to know nothing about them).

GiteaMirror commented

2026-04-13 04:25:53 -05:00

@CanRau commented on GitHub (Nov 19, 2025):

Great point so yea in my case a custom db adapter is probably the way to go I guess

@CanRau commented on GitHub (Nov 19, 2025): Great point so yea in my case a custom db adapter is probably the way to go I guess

GiteaMirror commented

2026-04-13 04:25:54 -05:00

@realtebo commented on GitHub (Dec 4, 2025):

Thanks a lot to the dev team.

This feature is excellent.

Is working and we are using in production using v1. 4.5 and next 16.

Again. Thanks.

@realtebo commented on GitHub (Dec 4, 2025): Thanks a lot to the dev team. This feature is excellent. Is working and we are using in production using v1. 4.5 and next 16. Again. Thanks.

GiteaMirror referenced this issue

2026-04-13 07:37:20 -05:00

[GH-ISSUE #9101] docs: clarify if testUtils plugin is fine to unconditionally include in prod #11275

GiteaMirror referenced this issue

2026-04-13 10:38:55 -05:00

[PR #9119] docs(test-utils): clarify production usage #16697

GiteaMirror referenced this issue

2026-04-15 19:16:12 -05:00

[GH-ISSUE #9101] docs: clarify if testUtils plugin is fine to unconditionally include in prod #19906

GiteaMirror referenced this issue

2026-04-15 22:50:57 -05:00

[PR #9119] docs(test-utils): clarify production usage #25351

GiteaMirror referenced this issue

2026-04-17 20:02:19 -05:00

[GH-ISSUE #9101] docs: clarify if testUtils plugin is fine to unconditionally include in prod #28598

Sign in to join this conversation.

Branches Tags

2026-05-22/chore/adopt-agents-md

2026-05-22/refactor/string-case-utils

dependabot/npm_and_yarn/uuid-14.0.0

dependabot/npm_and_yarn/turbo-2.9.14

changeset-release/main

main

2026-05-14/fix/passkey-verify-error-and-claim

dependabot/npm_and_yarn/samlify-2.13.0

dependabot/npm_and_yarn/ws-8.20.1

changeset-release/next

dependabot/npm_and_yarn/demo/electron/demo-minor-patch-519ef7475f

dependabot/github_actions/github-actions-98f3470200

client-assertions-main

2026-05-15/ci/fix-sqlite-abi-mismatch

2026-05-15/fix/organization-team-add-cascade

2026-05-15/fix/parse-set-cookie-value-validation

2026-05-13/feat/captcha-wildcard-endpoints

2026-05-13/ci/stabilize-docker-startup

fix/i18n-before-hook-translation

fix/disable-migration-generate

2026-05-07/fix/admin-set-password-upsert

2026-05-10/fix/cookie-drain-order

2026-05-10/feat/hooks-finally

2026-05-09/fix/cookie-drain-order

2026-05-09/feat/hooks-finally

2026-05-08/feat/register-before-send

fix/stripe/subscription-data-merge

2026-05-01/chore/pnpm-v11-harden

chore/pnpm-v11

2026-04-29/feat/google-include-granted-scopes

2026-04-29/fix/oauth-account-scope-semantics

2026-04-27/fix/nextcookies-idempotent-writes

2026-04-26/fix/harden-proxy-host-validation

2026-04-26/refactor/stripe-callback-signature-cleanup

2026-04-26/fix/stripe-subscription-callback-timing

2026-04-11/fix/sveltekit-app-modules

feat/open-api-zod-contract

feat/oauth-provider-backchannel-logout-next

feat/oauth-idp-initiated-bounce

refactor/sign-in-challenges

2026-04-21/fix/oauth-rfc-input-validation

fix/release-notes-new-packages

fix/two-factor-identity-guard

fix/resource

feat/emailpassword-authorize

2026-04-12/security/dynamic-baseurl-proxy-trust-default

feat/oauth-provider-at-hash-v2

fix/release-grep-fallback

claude/address-review-comments-JhFLr

claude/slack-update-stripe-docs-consistency-8Sc0w

feat/async-auth

fix/two-factor-totp-verified-enrollment

feat/plugin-ui

codex/blog-1-6-release-post

2026-04-06/fix/type-any-guards

2026-04-05/chore/downgrade-better-call

2026-04-04/ci/skip-vercel-fork-prs

2026-03-28/ci/add-autofix-ci

chore/release-preview-script

himself65/2026/02/19/role

2026-03-24/fix/update-user-info-on-link

2026-03-20/docs/improve-website

2026-03-20/fix/anonymous-onlinkaccount-expo

2026-02-17/fix/anonymous-link-state

fix/8607-saml-inresponseto

fix/8549-scim-patch-noop

v1.4.x

refactor/migration-snapshot-tests

worktree-magic-link-additional-data

chore/migrate-build-to-rollup

worktree-fix-dynamic-baseurl-8447

2026-03-06/chore/public-api-check

fix/close-8156-regression-test

fix/secondary-storage-json-error-handling

himself65/verification-namespace

cursor/issue-8307-validation-79a3

himself65/2026/01/30/error-mdx

v1.4.x-staging

fix/email-otp-user

fix/restrict-full-organization-access-roles

himself65/2026/02/12/count

himself65/2026/02/04/define-plugin

2026-02-04/feat/add-pluralize

cursor/better-auth-js-integration-ec21

cursor/expo-state-mismatch-394c

2026-02-01/fix/org-update-role-sync-members

cursor/issue-7607-investigation-e146

cursor/email-generation-helper-0ff6

himself65/2026/01/21/avoid-spread-operator

himself65/2026/01/14/cli

claude/slack-add-docs-pr-NMvgO

claude/slack-add-advanced-useplural-WHKYL

feat/hooks-pos

feat/2fa-phone

feat/2fa

fix/rotation

fix/username-check

v1.3.x

refactor/organization

feat/multiple-client-ids-social-providers

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/better-auth#9101