OIDC refresh token lost if not resent by provider

[sdaschner]

Describe the bug
When using Google OpenID Connect as Quarkus OIDC provider, the application receives both an access and refresh token, when access_type=offline is sent to Google.

It work that Quarkus uses this refresh token under the hood to refresh the expired access token, however, Google sends the refresh token only for the very first time (and never again), when a token is requested.

CodeAuthenticationMechanism then causes the refresh token to be lost in the q_session cookie, since it overrides the value with the result from the refresh, and there the refresh token is non-existent.

Expected behavior
To save and reuse the refresh token, since it might not be resent -- this is the case for Google, not sure how other OIDC providers do this.

Potential fix

I've fixed this issue in my project by manually building quarkus-oidc with the following patch

Happy to provide a PR, however, I'm not quite sure whether this is just a dirty hack or solves it in all solutions; in general, it would be good if the OIDC extension wouldn't loose refresh tokens that are only issues once, like for Google.

[sberyozkin]

@sdaschner Hi, thanks for spotting it, definitely, please provide a PR, if the refresh token grant succeeds but IDP chooses not to recycle RT then indeed we need to keep the current one.
Can you open a PR today please ? I'm on PTO from next week so I'd like to fix it by the end of the week. thanks
CC @pedroigor

[sdaschner]

Sure, happy to do so (just couldn't comment on any other use case, have only tested the one I have with Google OIDC)

#10931

[sberyozkin]

@sdaschner Thanks; we test against Keycloak which prefers to recycle RTs (which is recommended since RTs are long lived and powerful so the impact associated with them being misused is high), but I think in this case it is nearly an NPE fix, so a simple PR you have provided is OK