search

aws-samples / amazon-cognito-passwordless-auth

Passwordless authentication with Amazon Cognito: FIDO2 (WebAuthn, support for Passkeys), Magic Link, SMS OTP Step Up
Apache License 2.0
367 stars 63 forks source link

signInStatus is 'NOT_SIGNED_IN' during refresh of token #166

Open philipbeber opened 4 months ago

philipbeber commented 4 months ago

I've noticed that if the token needs to refresh (i.e. I haven't used our app for more than an hour) then the login screen briefly appears while the token is refreshing. This is really annoying. It seems that signInStatus and signingInStatus go through these transitions:

signInStatus: CHECKING signingInStatus: CHECKING_FOR_SIGNIN_LINK signInStatus: NOT_SIGNED_IN signingInStatus: NO_SIGNIN_LINK signInStatus: REFRESHING_SIGN_IN signingInStatus: NO_SIGNIN_LINK signInStatus: SIGNED_IN signingInStatus: NO_SIGNIN_LINK

The NOT_SIGNED_IN status is messing us up and seems erroneous. I had a look at the code. I don't quite understand it but I think maybe a call to setIsSchedulingRefresh(true) would fix the problem? I don't see that isSchedulingRefresh is ever set to true. I think maybe it should be done just before line 205 of hook.tsx. What do you think?

Btw to repro this you can either wait an hour or just edit Passwordless.<longid>.expireAt to be some old date, in local storage.

Thanks!

ottokruse commented 4 months ago

Hi mate!

The signInStatus should be REFRESHING_SIGN_IN then because either isSchedulingRefresh or isRefreshingTokens should be true: https://github.com/aws-samples/amazon-cognito-passwordless-auth/blob/10c696371b84e41fcbcd8033f314bb6f73f79d1e/client/react/hooks.tsx#L333-L334

Which means you should see this (if you use the pre-built Passwordless component): https://github.com/aws-samples/amazon-cognito-passwordless-auth/blob/10c696371b84e41fcbcd8033f314bb6f73f79d1e/client/react/components.tsx#L101-L114

Are you indeed using the pre-built Passwordless component? Does this work like that for you, but you're saying I don't want to see that page in this case?

Else, if you do see signInStatus is NOT_SIGNED_IN, and not REFRESHING_SIGN_IN, we need to figure out what goes wrong. That is a bug then.

You should not have to look at signingInStatus by the way. Just looking at the field signInStatus should be enough to figure out whether or not to show sign in page (was made for that purpose). Since being signed in (=have valid JWTs), and signing in, can exist in parallel (eg in case of step up auth), these statuses were separated into two different fields (they are related but not the same).

philipbeber commented 4 months ago

Hi! Thanks for the quick response. I just tried with the sample app and it behaves how you said it should, it goes straight to the REFRESHING_SIGN_IN state. I'm not sure why our app is hitting the CHECKING and NOT_SIGNED_IN states. I will dig into it later this week to see what we are doing differently.

ottokruse commented 3 months ago

Any luck finding out?