@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?

@mark-robustelli
It was already disabled on application level.

@mark-robustelli
It is disabled on application level but I don't see any such option for tenant.
How to disable it for tenant ?

@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?

@mark-robustelli

1. No
2. No, the FA version is 1.55.1
3. Yes, we use webhooks to sync user info (like email change) between FA and our application
4. No, for our application FA is the only IdP, however we use migration mechanism to add new users to the FA DB from application

@mark-robustelli
Sometimes user sees this:

@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.

The interval between authorization attempts in event logs (at least 10 sec between them) points to the human attempts and we see the login doubling often happens on the next day so we suspect the following scenario: user leaves the application page not closing it and is logged out due to inactivity, which means he is redirected to FA login page and uses it next day. We think the FA login page after some period of time "expires" (some login id in cookies or something like that) and further OAuth negotiation on application side fails, user is redirected back to the fresh FA login page, enters credential again and login succeeds.

How can we increase or disable that FA login page expiration?

@mark-robustelli

Also we have 3 login records and only 2 corresponding entries (for the same minute) in event logs:

@mark-robustelli

We have the following records in event log for doubled logins at the same minute:

OAuth2 exchange authorization code debug log for [******] with clientId [XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX055].

6/25/2025 07:17:54 PM Z Validate the provided authorization code [VqER3sOWcAn2RuONY0BPHK-_TAt3hb1y92fwwj8mDNY].
6/25/2025 07:17:54 PM Z Validate PKCE code_challenge [crUqHYRAXwg-yyUFsei4-I9rmZ1SQiz0sC76ARgPtYA] provided during the authorization request with the provided code_verifier [pDyk_bw-BKUPyCfpTcVn694YoutV9_2gH0yIP09710g]. Calculated code_challenge [crUqHYRAXwg-yyUFsei4-I9rmZ1SQiz0sC76ARgPtYA].
6/25/2025 07:17:54 PM Z Scopes requested [openid profile email]
6/25/2025 07:17:54 PM Z Ensure the provided request parameters match those provided the authorization request.
6/25/2025 07:17:54 PM Z User is registered for application with Id [XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX055] the [roles] and [applicationId] claims will be added.
6/25/2025 07:17:54 PM Z The authorization code has been successfully exchanged for an access token.

OAuth2 exchange authorization code debug log for [******] with clientId [XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX055].

6/25/2025 07:17:44 PM Z Validate the provided authorization code [BjWl6NxsoTZG_wqCOaBegQzWbDI8WBnid4sPQDk9eCM].
6/25/2025 07:17:44 PM Z Validate PKCE code_challenge [h-n3xKiN9XmcWtJOBbALv6S4Rf9w-LSeuFgoxJIT8bU] provided during the authorization request with the provided code_verifier [ptFznenHB4Mq4fhsRi-h77GPA1XCkWgl2XpPAPYJaK0]. Calculated code_challenge [h-n3xKiN9XmcWtJOBbALv6S4Rf9w-LSeuFgoxJIT8bU].
6/25/2025 07:17:44 PM Z Scopes requested [openid profile email]
6/25/2025 07:17:44 PM Z Ensure the provided request parameters match those provided the authorization request.
6/25/2025 07:17:44 PM Z User is registered for application with Id [XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX055] the [roles] and [applicationId] claims will be added.
6/25/2025 07:17:44 PM Z The authorization code has been successfully exchanged for an access token.