Session storage does not work when user is redirected back to the application after resetting password.

[soofstad]

Session storage does not work when user is redirected back to the application after resetting password.

[soofstad]

All right. Thats good to hear 🥳

But the keys used for the authentication flow ( codeVerifier, state) must be in session storage. If not, authentication will fail if more than one tab/browser is open, and both tries to re-authenticate at the same time.
I don't see any other solution to this.

[harmoney-ryanli]

I agree with the conclusion. Closed this issue and the PR #82
Thanks mate @soofstad @sebastianvitterso .

[soofstad]

Hi again @harmoney-ryanli 👋
Interesting problem. I've never seen anything related to "registration" being mentioned in the OAuth2 spec, and so is a bit reluctant to bring this into the project. As I think it can solved in other ways.

Do you have a link to some API documentation where this flow is described? If it's a common practice perhaps #82 could be merged.

[harmoney-ryanli]

Hi again @harmoney-ryanli 👋 Interesting problem. I've never seen anything related to "registration" being mentioned in the OAuth2 spec, and so is a bit reluctant to bring this into the project. As I think it can solved in other ways.

Do you have a link to some API documentation where this flow is described? If it's a common practice perhaps #82 could be merged.

Hi @soofstad , I think I've found a solution for registration without adding the register method, I can pass an extra parameter in the login page, then configure a conditional flow to redirect the user to registration page. I'll revert the register-related change.
But for the storage used to store code verifer, are you happy I make it configurable? @soofstad

[harmoney-ryanli]

@soofstad but it does not make sense to authenticate at the same time, how can a user do the authenticate at the same time, he needs time to switch from one tab to another one, then we can use the loginInProgress to check if login in progress, do nothing.

[sebastianvitterso]

I'll describe a situation (that has happened with web-applications using this library).

Initially, the application is open in two tabs, which works well.
Then, the user puts their computer in sleep mode, which suspends JS execution, but does not unmount the website (meaning it does not refresh once the computer is woken up).
Opening the computer e.g. the next day, the auth token is outdated, and the application will attempt to re-authenticate.
This happens in both open tabs, which both generate a code challenge token. This token is then stored to the selected storage.
In the case of localStorage, they write to the same storage, so the last one overwrites the first one's challenge.
Upon returning after authorizing with OAuth, both tabs validate the code given to them by the oauth provider against the code challenge they had initially.
Since both tabs initially had unique challenges, but localStorage only contains the last tab's challenge, the first tab's authentication will fail.

I think this case is correct, @soofstad?

Finally, if the user has N tabs open, N-1 of them will fail their (possibly automatic) re-authentication, and be handed an error page. This isn't the desired behaviour, I think.

[soofstad]

Sebastian laid out the scenario well. Also, keep in mind that the "re-authentication" can happen without any user input. The authprovider often store cookies, so that the user does not need to input username/password, just a very fast redirect and callback, with no user interaction.

[soofstad]

To go at it from another angle; which scenario do you need the verificationCode to be in localstorage and not sessionstorage?

[harmoney-ryanli]

That makes sense, thanks for the explanation @sebastianvitterso .
The scenario is the one I described in the issue description. The user reset password in a new tab, then sign in automatically and is redirected back to the application, but cannot find the code verifier in the session storage, because it's in a new tab.

[soofstad]

Okey, I think it's that flow I'm struggling a bit to understand. Not sure how he can reset password if the user is not already authenticated. Or is that happening at the authprovider? Ether way, I would expect to re-login to any apps if I have reset my password for that authprovider.

I see what you are trying to do. But I don't think its a good idea, design wise, to mix this register feature with the oauth2 authentication flow in your application.

[soofstad]

So to sum up:

• Any "registration flow" should not be mixed with the OAuth2 Authorization Code Grant flow
• CodeVerifier must be in sessionStorage to avoid bugs with multiple tab/windows being open at the same time.

If you agree on the conclusion on this @harmoney-ryanli, feel free to close the issue.