High latency login problems

[polsson12]

Hi Janssen team,

Over the last couple of days I’ve been investigating an issue affecting users with high response times (e.g. users abroad or on poor connections) during login.

I’ve traced the behavior to this block in AuthorizeRestWebServiceImpl.java where prompt=login is added if the request has taken more than 500 ms:

jans/jans-auth-server/server/src/main/java/io/jans/as/server/authorize/ws/rs/AuthorizeRestWebServiceImpl.java

Lines 680 to 687 in 92796fb

	private void addPromptLoginIfNeeded(AuthzRequest authzRequest, Client client) {
	if (identity != null && identity.getSessionId() != null && identity.getSessionId().getState() == SessionIdState.AUTHENTICATED
	&& Boolean.TRUE.equals(client.getAttributes().getDefaultPromptLogin())
	&& identity.getSessionId().getAuthenticationTime() != null
	&& new Date().getTime() - identity.getSessionId().getAuthenticationTime().getTime() > 500) {
	authzRequest.addPrompt(Prompt.LOGIN);
	}
	}

What we’re seeing is:

1. The user is authenticated earlier in the flow with prompt=login.
2. Due to high latency, the 500 ms threshold is exceeded.
3. prompt=login is then added and the user is redirected to the authorize URL again.
4. This effectively forces an unnecessary re-login, causing a bad UX for our high-latency users and eternal login loops.

jans/jans-auth-server/server/src/main/java/io/jans/as/server/authorize/ws/rs/AuthorizeRestWebServiceImpl.java

Lines 675 to 676 in 92796fb

	log.debug("prompt=login, redirect to authorization page, request {}", authzRequest);
	throw new NoLogWebApplicationException(redirectToAuthorizationPage(authzRequest));

My questions are:

1. What is the rationale for this 500 ms check and the automatic addition of prompt=login above that threshold?
2. Would you consider making this behavior configurable or providing an alternative approach for environments with higher latency?

This behavior is currently causing significant issues for us in production, so any guidance or recommended workaround would be greatly appreciated.

Thanks in advance!

[yuriyz]

It was added in 2022. Original code had 200ms and then it was increased to 500ms.

615c64c#diff-dc4e97e7dcc343c6482592656599da16cbdda68f094e06c7998b024442c8755d

I believe the rationale of this check is that it's not expected that at that code point session's authenticated is older then 500ms.
I guess it's first time we got feedback about it since 2022.
We definitely can make it configurable.
Scheduled ticket #12802

[polsson12]

Hi, thanks for the quick reply!

When do you expect this fix to be released roughly?
And is there any more detailed analysis behind it than “it’s not expected” — e.g. potential security concerns or similar?

[yuriyz]

Issue was solved here #12821
It gives ability to configure threshold and also entirely skip it.
It's now in main and should be available with next release.

[polsson12]

Awesome, thanks!

[nynymike]

Ollson-san, can you send me a Linkedin conection request to https://www.linkedin.com/in/nynymike

[polsson12]

done!