github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-24 16:11:53 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #3229] Proposal: Add Feature Flag Support via Token Claims [Plugin] #9531

New Issue
Open
opened 2026-04-13 05:01:41 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-13 05:01:41 -05:00
Owner
Copy Link

Originally created by @AndrewCraswell on GitHub (Jul 1, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/3229

Originally assigned to: @ping-maxwell on GitHub.

Is this suited for github?

  • Yes, this is suited for github

Is your feature request related to a problem? Please describe.

It would be useful to add native support for feature flags via a plugin for Better-Auth, which would embed flight data directly in token claims (e.g., JWTs). This would allow downstream services to check flags instantly at runtime, without calling out to a feature flag service.

✅ Why this fits in Better-Auth

  • Auth already knows the user and tenant, so it's a natural place to include feature access.
  • Per-tenant and per-user config can be resolved once at token issuance.
  • Zero-latency checks in the frontend/backend — no extra HTTP calls needed.
  • Industry precedent:

⚠️ Downsides

  • Token size could grow with too many flags, especially in cookies or headers.
  • Adds complexity to token issuance (extra DB lookups, caching).
  • Unauthenticated users won’t benefit unless we support public flights.

🛠 Proposed Implementation

  • Add a flights or featureFlags claim to the token payload, optionally namespaced.
  • Store per-tenant and per-user flight data in the data source.
  • On token generation, resolve and inject the relevant flags based on:
    • Tenant-wide defaults
    • User-specific overrides (e.g., early access testers)

Describe alternatives you've considered

The alternative is generally rolling your own feature flights system which is generally rudimentary, or using a 3rd party service like LaunchDarkly, Vercel Feature Flags, Azure App Configuration, etc. These are paid services and require additional API requests and SDKs to integrate.

On the other hand, a tool like LaunchDarkly can provide fine-grained flighting and ring promotion details which is a much more complex scenario.

Additional context

No response

Originally created by @AndrewCraswell on GitHub (Jul 1, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/3229 Originally assigned to: @ping-maxwell on GitHub. ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. It would be useful to add native support for **feature flags** via a plugin for Better-Auth, which would embed flight data directly in token claims (e.g., JWTs). This would allow downstream services to check flags instantly at runtime, without calling out to a feature flag service. --- ### ✅ Why this fits in Better-Auth - **Auth already knows the user and tenant**, so it's a natural place to include feature access. - **Per-tenant and per-user config** can be resolved once at token issuance. - **Zero-latency checks** in the frontend/backend — no extra HTTP calls needed. - **Industry precedent**: - [WorkOS just launched this](https://workos.com/blog/feature-flags) - [Clerk has it on their roadmap](https://feedback.clerk.com/roadmap) --- ### ⚠️ Downsides - **Token size** could grow with too many flags, especially in cookies or headers. - **Adds complexity** to token issuance (extra DB lookups, caching). - **Unauthenticated users** won’t benefit unless we support public flights. --- ### 🛠 Proposed Implementation - Add a flights or featureFlags claim to the token payload, optionally namespaced. - Store per-tenant and per-user flight data in the data source. - On token generation, resolve and inject the relevant flags based on: - Tenant-wide defaults - User-specific overrides (e.g., early access testers) ### Describe alternatives you've considered The alternative is generally rolling your own feature flights system which is generally rudimentary, or using a 3rd party service like LaunchDarkly, Vercel Feature Flags, Azure App Configuration, etc. These are paid services and require additional API requests and SDKs to integrate. On the other hand, a tool like LaunchDarkly can provide fine-grained flighting and ring promotion details which is a much more complex scenario. ### Additional context _No response_
GiteaMirror added the core label 2026-04-13 05:01:41 -05:00
GiteaMirror commented 2026-04-13 05:01:43 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Jul 1, 2025):

Hey good idea, I'll see if I can get to it in the future (may be a long while from now)
I'll add it to our backlogs.

<!-- gh-comment-id:3021673699 --> @ping-maxwell commented on GitHub (Jul 1, 2025): Hey good idea, I'll see if I can get to it in the future (may be a long while from now) I'll add it to our backlogs.
GiteaMirror commented 2026-04-13 05:01:43 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Sep 30, 2025):

Hi, @AndrewCraswell. I'm Dosu, and I'm helping the better-auth team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You proposed adding native feature flag support in Better-Auth by embedding flag data directly in token claims.
  • This approach aims for instant, zero-latency feature checks without external calls.
  • It would support per-tenant and per-user configurations at token issuance.
  • A potential downside is increased token size and complexity.
  • The idea was positively received and added to the backlog by the maintainer, but no implementation timeline is set.

Next Steps:

  • Please let me know if this feature is still relevant to your needs with the latest version of better-auth by commenting here.
  • If I don’t hear back within 7 days, I will automatically close this issue to keep the backlog manageable.

Thanks for your understanding and contribution!

<!-- gh-comment-id:3352874522 --> @dosubot[bot] commented on GitHub (Sep 30, 2025): Hi, @AndrewCraswell. I'm [Dosu](https://dosu.dev), and I'm helping the better-auth team manage their backlog and am marking this issue as stale. **Issue Summary:** - You proposed adding native feature flag support in Better-Auth by embedding flag data directly in token claims. - This approach aims for instant, zero-latency feature checks without external calls. - It would support per-tenant and per-user configurations at token issuance. - A potential downside is increased token size and complexity. - The idea was positively received and added to the backlog by the maintainer, but no implementation timeline is set. **Next Steps:** - Please let me know if this feature is still relevant to your needs with the latest version of better-auth by commenting here. - If I don’t hear back within 7 days, I will automatically close this issue to keep the backlog manageable. Thanks for your understanding and contribution!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label core
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#9531
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?