Doubling of login records
-
@sergey_smirnov Hmm, the 10 sec between the logs does lead me to similar speculation that it is being caused by the user. I would think they would be closer together if it was something the application was doing on its own (although I am not entirely ready to rule that out either).
That being said, it seems like just guessing unless you can get the application logs and trace the users page views for sure. Is that possible?
There is a setting in the Tenants for the Session timeout.
Tenants -> Edit -> OAuth tab -> Session timeout
Let me know if you are able to log the users page views.
-
@mark-robustelli
Yes, we have access to HTTP requests to our application but not to FA server.
We already tried to adjust all timeouts options in admin panel (for OAuth and JWT) and it doesn't affect the "expiration" of FA Login form. I mean the login form we see after logout with message "You have been logged out of ..." on top of it. If you enter credentials there on the next day (the same day works fine) it may fail to login from the first attempt. -
@mark-robustelli
Sometimes user sees this:
-
@sergey_smirnov OK, I did some investigating and here is what I have found.
- SSO, I saw a reference to a post that mentions using SSO will create multiple session records (but shouldn't necessarily cause multiple login events). Are you using SSO?
-
Are you using any Lambda's? In some versions (notably 1.31.0), a bug caused the OIDC reconcile lambda to be called twice during certain identity provider logins, which could result in duplicate processing and potentially duplicate events. This was patched in version 1.32.1.
-
Are you using any Webhooks?
-
Are you using an external IdP?
These are just a couple of things to consider.
-
- 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.
