State cookies (q_auth) keeps piling up in code flow about quarkus

[quarkus-bot]

/cc @pedroigor (bearer-token,oidc), @sberyozkin (bearer-token,oidc)

[sberyozkin]

@segersb What Quarkus version is it ? The state cookie is removed the moment it is detected, and we have a good number of tests confirming it is null at the end.
What I will do, I'll update https://github.com/quarkusio/quarkus-quickstarts/blob/main/security-openid-connect-web-authentication-quickstart/src/test/java/org/acme/security/openid/connect/web/authentication/CodeFlowTest.java to double check it and then if it works as expected I'll ask you to modify that test to reproduce the problem

[segersb]

We're on the laster 3.9.4

I did notice "removeCookie" calls in the "CodeAuthenticationMechanism" class
However it seems those are called when the flow processes the redirect, not in the initial getChallenge

[sberyozkin]

@segersb It should not really matter as the token removal happens on the response object.

I've added a simple test at quarkusio/quarkus-quickstarts#1418

I think the one which would be of most relevance is the token timeout test, see changes from here:

https://github.com/quarkusio/quarkus-quickstarts/pull/1418/files#diff-85ab775ab6e475a9e48a41ce6fd86bd166bc450be0056b119f11644a9bdb8724R71

So initially we have a single state cookie. After the successful login, it is null. Now the session expires and again, we only have a single state cookie.

What I'd like to ask you is to modify the test in that PR (if you'd like please wait until it is merged into the development branch) to have that test failing with having more than 1 state cookie at a time.

Please also try 3.10.CR1.

It sounds like you may have concurrent authentication requests (multiple tabs, threads) for the same user (as opposed to a typical single tab flow) , in which case, indeed, a new unique state cookie is created to track each of these authentications and if one of these parallel authentications is not completed, the state cookie will accumulate.
Quarkus can't delete all of them, the way you do it, as it will break the multi-tab authentication.

If you don't do a multi-tab authentication, then the only other reason I can think of is that the parallel heartbeats may be overlapping with the actual authentication requests, i.e, you still have essentially a multi-tab authentication.

What you can do here is just disable the multi-tab:
quarkus.oidc.authentication.allow-multiple-code-flows=false

That may actually be what will fix it for you

[sberyozkin]

@segersb But in any case, I can also do what I've been thinking about doing for a long time and never done, the state cookie age is set to 30 mins by default, it should be set max to 5 mins by default and users should be able to tune it to 1 min if they need to, which will accelerate the browser getting rid of any stale state cookies

[segersb]

We ran into a problem because we use Vaadin for our frontend, and it sends out heartbeat requests. These heartbeats don’t interact with OIDC, so when the access token expires, each request ends up creating a new cookie. We can adjust the heartbeat interval, but if a heartbeat fails due to an expired token, it tries again every second. This was a problem even though the cookies are only good for 30 minutes.

Setting the property like you suggested worked out great. Our own fix, where we expire the tokens ourselves, does pretty much the same thing. I’m not totally sure when you'd need multiple code flows, but if that's the standard and it's working as intended, then it's all good.

Thanks for your help. I’m going to close the ticket now.

[sberyozkin]

Thanks @segersb, I'll re-open just so that I remember to do this task of having the state cookie timeout controlled better, and will close once that is done, thanks