feat(custom-flows): signUpIfMissing sign-in-or-up#3202
Conversation
Add documentation for `signUpIfMissing` sign-in-or-up flows. Frame these as an alternative to the standard approach, with tradeoffs including restrictions and a delay in providing feedback to end users on whether their account exists.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| // the code 'sign_up_if_missing_transfer'. Check for this error | ||
| // to determine if we need to transfer to sign-up. | ||
| if (error) { | ||
| if (error.errors[0]?.code === 'sign_up_if_missing_transfer') { |
There was a problem hiding this comment.
In the new Core 3 SignIn, we have signIn.isTransferable. This checks the verification in the piggybacked object on the error. This is what we use for OAuth transfers. Unfortunately, it just doesn't work in this case. According to Claude (I am not a React expert), that's because we are checking a stale snapshot:
The piggybacking updates the underlying SignIn resource in-place, but the React hook snapshot is stale until the next render. Since we're checking signIn.isTransferable synchronously in the same await chain, React hasn't re-rendered yet.
Therefore, we have to manually check the error code itself. This custom flow is already complex, but if it would help to add an SDK helper here (or anywhere) I'm very happy to do so.
|
Hi @alexisintech, I believe you worked on the Core 3 custom flow docs, so I wanted to tag you if you'd be able to take a look at my attempt to put together a 'signUpIfMissing' custom flow guide. |
|
|
||
| ## Enable email and password authentication | ||
| - [**Standard flow**](#standard-sign-in-or-up-flow): The sign-in attempt immediately tells you whether an account exists. If it doesn't, you start the sign-up flow. This is simple and gives users immediate feedback, but it reveals whether an account exists before any verification, making it susceptible to [user enumeration](/docs/guides/secure/user-enumeration-protection) attacks. | ||
| - [**`signUpIfMissing` flow**](#sign-in-or-up-with-signupifmissing): The sign-in proceeds to verification regardless of whether an account exists. Only after verification does the backend reveal whether the account exists or needs to be created. This prevents user enumeration attacks. |
There was a problem hiding this comment.
does this only happen if the user has user enumeration protection enabled?
There was a problem hiding this comment.
You can use this custom flow without enabling strict enumeration protection first. That has a lot of holes though: UserProfile is unprotected, and an attacker could just manually send FAPI requests.
I implemented it with them separate because it seems like some people ask for this as an alternative to strict enumeration protection, it's like "kind of enumeration protection". Also it's possible that some customers could like the way it does verification upfront.
|
This looks great, thank you so much for the suggestions @alexisintech! It all makes sense and looks clear to me. |
2 participants
🔎 Previews:
What does this solve? What changed?
Add documentation for
signUpIfMissingsign-in-or-up custom flows. Frame these as an alternative to the standard approach, with tradeoffs including restrictions and a delay in providing feedback to end users on whether their account exists.Three additional notes:
SDK releases are broken (?) at the moment so the underlying SDK changes have not yet been released, but it should be released very soon.SDK releasedDeadline
It would be nice to be comfortable with sharing some form of this with Spark by end of week (March 13).
There's no rush on a broad release.
Other resources