OIDC authentication loop if Cookie Policy sameSite=strict

[yoadey]

Description

Using the OIDC authentication code workflow may lead to a loop of authentication requests, if not properly configured and currently there is no hint to that in the Documentation.

If the user visits the app for the first time, the current default setting of quarkus.oidc.authentication.cookie-same-site=strict leads to the following chain:

1. user is not authenticated, goes to https://example.org/login, response is

302 Found
location: https://provider.org/oauth/authorize?response_type=code&client_id=XXXX&state=YYYY&...
set-cookie: q_auth=YYYY|/login?code=XYZ&state=YYYY; Max-Age=1800; Path=/; HTTPOnly; SameSite=Strict

2. User is redirected to provider.org and has to grant the new App permissions for authentication
3. Provider redirects the user to example.org with code & state (Not 302 calls, as user action required!)
4. Because of the sameSite=Strict policy, the q_auth cookie is not send to example.org. So it retriggers an authentication with similar request as in 1
5. User is redirected to provider.org
6. provider.org sends 302 redirect to example.org with code & state, as already logged in
7. 302s were originally started from example.org, so cookie is sent and user is successfully authenticated (could not test that, just my understanding)

So after an additional roundtrip, the user is authenticated and everything is ok (if it works as I understand it).

However, if provider.org does not send a 302 for the redirection but an html page with a javascript redirect (e.g. gitlab, the only provider I currently test with) this leads to a loop, since the request is originated always from provider.org and with sameSite=strict the cookie will never be send.

It's not a bug as it can be configured and many providers probably do the redirect with a 302, but I think it is worth noting in the documentation.

The following setting solved the issue for me:

quarkus.oidc.authentication.cookie-same-site=lax

Implementation ideas

No response

[quarkus-bot]

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

[sberyozkin]

@yoadey Thanks, we should update the quarkus.oidc.provider=github to have a lax setting, and indeed note in the docs it may have to be lax.

[sberyozkin]

Oh you mean gitlab...

[yoadey]

Yes, I meant Gitlab, sorry for the confusion. Just checked for GitHub, they do a 302 redirect and then the Strict cookies are correct send (at least if you have the app already approved).

But could also confirm, that a second roundtrip is required in case the app has not been authorized yet. This shouldn't be to much of an issue, but is probably worth mentioning, too.

[sberyozkin]

@yoadey Np at all, you did say clearly in the description it was gitlab,

Provider redirects the user to example.org with code & state (Not 302 calls, as user action required!)
However, if provider.org does not send a 302 for the redirection but an html page with a javascript redirect (e.g. gitlab, the only provider I currently test with)

That seems to be very much specific to GitLab. By the way, how complex is the quarkus configuration to get OIDC with GitLab supported, we can support quarkus,oidc.provider=gitlab if you'd like

[yoadey]

@sberyozkin It was pretty straightforward, working with the basic setting quarkus.oidc.auth-server-url, quarkus.oidc.client-id and quarkus.oidc.credentials.secret. Now the additional quarkus.oidc.authentication.cookie-same-site=lax property needs to be set, but I don't know whether this is sufficient for a custom provider.

As for us GitLab is a self hosted instance, the auth-server-url has to be set anyways and we wouldn't save much configuration.

[wjglerum]

We just hit the same problem with Azure AD here, setting the config quarkus.oidc.authentication.cookie-same-site=lax fixed the issue indeed. Could we maybe add this to the migration guides too? Because I couldn't find them here https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.16

[sberyozkin]

Sure

[sberyozkin]

Thinking more about it, if I confirm that even that the OIDC tests pass, the extra redirect with Keycloak is involved, then I will just fix it by removing a strict for the state and logout cookies. This will need to stay for the session cookie only which is a primary restriction target.

[sberyozkin]

@yoadey @wjglerum I'll be reverting the change related to OIDC state and logout cookies. It does not even work with Keycloak with the browser unless these cookies are same site lax. HtmlUnit has no problems though.
I'm glad it can be easily enough resolved by configuring the property but since the same site strict does not even make sense for the state/logout cookies due to the cross site redirects, it was a mistake on my part.

[wjglerum]

thanks for getting back on this @sberyozkin 👍 And makes sense to me to revert those cookie changes indeed.

[debu999]

thanks lax being the default fixed the issue.