OIDC changes in Quarkus upgrade from 2.16.5.Final to 3.2.10.Final

[kirankolli-addepar]

I am noticing some changes in the way authentication with keycloak is behaving b/w my current version and the version I would like to upgrade to.
with 2.16.5.Final when I used to hit 'Authorize' on my Swagger-UI it used to authenticate me with keycloak but never used to prompt me for selecting the roles the client needs to inherit. I am guessing the client automatically inherited all the roles that the user had.
Now post upgrade to 3.2.10.Final its prompting me to also select the roles to inherit. Is there a way to revert to defaulting to earlier behaviour i.e. inherit all roles available to the user without having to select which roles to inherit ?

[quarkus-bot[bot]]

/cc @pedroigor (oidc), @sberyozkin (oidc)

[sberyozkin]

@kirankolli-addepar Can you please create a reproducer ? Sounds like it is something related to the way Swagger UI controls the authentication

[kirankolli-addepar]

@sberyozkin here is the reproducer app which is a basic app. Another issue this app is exhibiting is that the swagger ui becomes unresponsive after current auth token expires and it does not prompt for a re-login.
code-with-quarkus 6.zip

[sberyozkin]

@kirankolli-addepar

quarkus.oidc.token-state-manager.split-tokens=true

This property is affecting the way the OIDC web-app endpoints saves the cookie, but Swagger UI is not depending on OIDC web-app at all to control the authentication, it does it independently from Quarkus.

Assuming the problem is not with Swagger UI but with Quarkus OIDC web-app, the fact that in 3.2.10 you have to set quarkus.oidc.token-state-manager.split-tokens=true may imply that the newer Keycloak produces bigger tokens or may be you are seeing only now the effect of the cookies exceeding the 4K barrier.

FYI. in 3.7.x, Quarkus will itself split the session coolie automatically

[kirankolli-addepar]

@sberyozkin what about the part of default changing to authenticated in the above two properties ? Is this a change people are expected to do since I could not find anything in the migration guide related to this.

[sberyozkin]

@kirankolli-addepar

default is only a policy name, same as authenticated which you replaced default with. I'm not aware of any reserved words, Michal, @michalvavrik, do you know something about it:

According to @kirankolli-addepar

quarkus.http.auth.permission.default.paths=/*
quarkus.http.auth.permission.default.policy=authenticated

does not work in 3.2.10

but

quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated

works.

@kirankolli-addepar Please create a simple reproducer where

quarkus.http.auth.permission.default.paths=/*
quarkus.http.auth.permission.default.policy=authenticated

does not work, where only changing from default to authenticated fixes things.

[michalvavrik]

Agreed, HTTP permission name is ignored anyway, so I can't imagine it having any effect unless there is a bug / change in SR Config. I'd need reproducer before I try it. Thanks