Doubling of login records
-
- No
- No, the FA version is 1.55.1
- Yes, we use webhooks to sync user info (like email change) between FA and our application
- No, for our application FA is the only IdP, however we use migration mechanism to add new users to the FA DB from application
-
@sergey_smirnov OK. It doesn't seem like the webhook you are using would cause the duplicate logins. I came across this post stating that exchanging a refresh token counts as a login event. I'm wondering if something like the user logins in using a new tab, then goes back to the old tab that triggers a refresh. If that is the case, that could account for the delay between logins and the "Something doesn't seem right" message as that session is no longer valid because of the new login. You might be able to verify this by using a webhook. There is a JWT.Refresh event that you might be able to log somewhere to see if it fires around the time of the duplicate log ins.
-
@mark-robustelli
No events. Also JWT duration is set to default 3600 (1 hour) for our application/tenant and as I see the option affects the timeout inside the corresponding claim only. As we don't use JWT we ignore it. Additional info; JWT Refresh Duration = 43200, OAuth session timeout = 3600.We see a lot of fusionauth cookies and hidden form fields which are updated during authentication process. How can we reset the login page (smth similar to incognito mode)? Maybe some parameters on logout?
-
@sergey_smirnov If you are not using the JWT, can you disable it in the AdminUI?
-
@mark-robustelli
It is disabled on application level but I don't see any such option for tenant.
How to disable it for tenant ? -
@sergey_smirnov I was referring to the application level. Try to disable it there and see if you are still getting the double login.
-
@mark-robustelli
It was already disabled on application level. -
@sergey_smirnov hmmm..Ok can we verify this is 100% not user action? Can you add some logging to your application so we can see what a user is clicking or starting a new session? Then we can compare with the logs in FusionAuth.
-
@mark-robustelli finally the issue is in FA counts as login attempt the GET request to /oauth2/authorize when user is already logged in on FA side (FA doesn't show login form in this case).
Scenario: user is not logged in, opens our site and is redirected to FA login page with setting OAuth correlation cookies on our domain, FA shows login form, user waits for 2 mins (standard expiration for correlation cookies) and makes POST request with credentials (login count +1). FA is authenticated on FA side now but user can't be validated on our side due to expired correlation cookies and is redirected back with fresh set of correlation cookies again to FA's /oauth2/authorize (login count +1) which already doesn't show login form (user is already authenticated on FA side) and just redirects to our signin-oidc which succeeds this time.
We added refresh of FA login form each 90 seconds in authorize template to refresh correlation cookies but it doesn't help if we enable 2FA and user stucks on entering code step more than 2 mins.
So, is it possible to fix the double counting on FA side?
-
@sergey_smirnov, it is awesome that you are able to follow and create steps to replicate the issue. To be 100% I'm not sure if this is a bug or a feature request. If FusionAuth is not behaving as you would like it, I would suggest opening an issue on Github. Be sure to include the details and repeatable steps.
