github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 07:18:56 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

Post-auth verification requirements / multi-step setup #2185

New Issue
Open
opened 2026-03-13 09:32:33 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-03-13 09:32:33 -05:00
Owner
Copy Link

Originally created by @proof-llc on GitHub (Oct 22, 2025).

Is this suited for github?

  • Yes, this is suited for github

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

It would be very useful if a user and session can be marked as requiring actions and thus not fully active. at present, we have emailVerified for a user, but it would be great to be more flexible so that we can add more requirements.

The same applies to sessions. The user has created an account and verified his email, better-auth will consider him logged in. I don't want him to be considered "fully" logged in" until he creates a passkey for that machine. whatever page he goes to, should force him to go to second step setup where a passkey has to be created.

Describe the solution you'd like

for instance, we could use a flag array for user and session table, and while the array is not empty, the user/session is considered not fully active/verified. Example, user hasn't signed terms 2.0, therefore user is not "fully" active until signing is complete.

Describe alternatives you've considered

i can write complex logic where user is logged in according to better-auth but i need to write a bunch of extra verification in middleware to determine if user is flagged for extra verifications.

Additional context

No response

Originally created by @proof-llc on GitHub (Oct 22, 2025). ### Is this suited for github? - [ ] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. It would be very useful if a user and session can be marked as requiring actions and thus not fully active. at present, we have emailVerified for a user, but it would be great to be more flexible so that we can add more requirements. The same applies to sessions. The user has created an account and verified his email, better-auth will consider him logged in. I don't want him to be considered "fully" logged in" until he creates a passkey for that machine. whatever page he goes to, should force him to go to second step setup where a passkey has to be created. ### Describe the solution you'd like for instance, we could use a flag array for user and session table, and while the array is not empty, the user/session is considered not fully active/verified. Example, user hasn't signed terms 2.0, therefore user is not "fully" active until signing is complete. ### Describe alternatives you've considered i can write complex logic where user is logged in according to better-auth but i need to write a bunch of extra verification in middleware to determine if user is flagged for extra verifications. ### Additional context _No response_
GiteaMirror added the enhancement label 2026-03-13 09:32:33 -05:00
GiteaMirror commented 2026-03-13 09:32:34 -05:00
Author
Owner
Copy Link

@proof-llc commented on GitHub (Oct 22, 2025):

This is related to https://github.com/better-auth/better-auth/issues/4396 not yet being resolved. If I can create an account with passkeys directly, i wouldn't need this. Since no passkey can be created during registration, this means I have to create a random password first (which user won't see). But that creates a verified account and a user may try to overcome the next step and jump to restricted sites before the passkey is created. In such case a user may have trouble logging in again since a passkey was never created.

@proof-llc commented on GitHub (Oct 22, 2025): This is related to https://github.com/better-auth/better-auth/issues/4396 not yet being resolved. If I can create an account with passkeys directly, i wouldn't need this. Since no passkey can be created during registration, this means I have to create a random password first (which user won't see). But that creates a verified account and a user may try to overcome the next step and jump to restricted sites before the passkey is created. In such case a user may have trouble logging in again since a passkey was never created.
GiteaMirror commented 2026-03-13 09:32:34 -05:00
Author
Owner
Copy Link

@proof-llc commented on GitHub (Oct 23, 2025):

The current architecture is a little inflexible and I think some restructuring is needed in the codebase to resolve both issues. I suggest that we introduce incomplete accounts which would live in secondary storage. whenever a user attempts to create an account, an incomplete object lives in secondary storage. the user proceeds to verify his email, now the account is complete, if we have configured for accounts to have no passwords or passkeys. if a password or passkey is required, then the account remains incomplete, until the user adds the missing piece. once all missing pieces are provided, the account is complete and it moves to to primary db where all complete accounts live.

@proof-llc commented on GitHub (Oct 23, 2025): The current architecture is a little inflexible and I think some restructuring is needed in the codebase to resolve both issues. I suggest that we introduce incomplete accounts which would live in secondary storage. whenever a user attempts to create an account, an incomplete object lives in secondary storage. the user proceeds to verify his email, now the account is complete, if we have configured for accounts to have no passwords or passkeys. if a password or passkey is required, then the account remains incomplete, until the user adds the missing piece. once all missing pieces are provided, the account is complete and it moves to to primary db where all complete accounts live.
GiteaMirror commented 2026-03-13 09:32:35 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Jan 22, 2026):

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

Issue Summary:

  • You requested a feature to mark users and sessions as requiring additional verification steps beyond email verification, such as mandatory passkey creation.
  • You highlighted related unresolved issues where passkey creation during registration forces creating a random password, risking users bypassing required steps.
  • You proposed restructuring with "incomplete accounts" stored separately until all verification steps are completed.
  • This approach aims to enable more flexible multi-step setup flows without complex middleware and improve the current inflexible architecture.
  • The issue remains unresolved with no recent updates.

Next Steps:

  • Please let me know if this issue is still relevant to the latest version of better-auth by commenting here to keep the discussion open.
  • Otherwise, this issue will be automatically closed in 7 days.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Jan 22, 2026): Hi, @proof-llc. 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 requested a feature to mark users and sessions as requiring additional verification steps beyond email verification, such as mandatory passkey creation. - You highlighted related unresolved issues where passkey creation during registration forces creating a random password, risking users bypassing required steps. - You proposed restructuring with "incomplete accounts" stored separately until all verification steps are completed. - This approach aims to enable more flexible multi-step setup flows without complex middleware and improve the current inflexible architecture. - The issue remains unresolved with no recent updates. **Next Steps:** - Please let me know if this issue is still relevant to the latest version of better-auth by commenting here to keep the discussion open. - Otherwise, this issue will be automatically closed in 7 days. Thank you for your understanding and contribution!
GiteaMirror commented 2026-03-13 09:32:35 -05:00
Author
Owner
Copy Link

@proof-llc commented on GitHub (Jan 23, 2026):

yes, still relevant

@proof-llc commented on GitHub (Jan 23, 2026): yes, still relevant
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 enhancement
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#2185
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?