OIDC Redis TokenStateManager does not work with Google

[Jaland]

Hey everyone,

I'm trying to use the quarkus-oidc-redis-token-state-manager extension to store OIDC session tokens in Redis. My goal is to maintain user sessions authenticated against Google, but I'm running into an issue where the refresh token's expiration isn't being stored correctly.

It seems like Redis is only using the access token's expiration time for the entire session entry. This causes the Redis key to expire when the short-lived access token does, which defeats the purpose of having a long-lived refresh token.

---

Configuration

Here's my basic setup in application.properties:

quarkus.oidc.credentials.jwt.key-id=jwtToken
# OIDC Provider (Google)
quarkus.oidc.auth-server-url=https://accounts.google.com
quarkus.oidc.client-id=YOUR_GOOGLE_CLIENT_ID.apps.googleusercontent.com
quarkus.oidc.credentials.secret=YOUR_GOOGLE_CLIENT_SECRET
quarkus.oidc-client.client-enabled=false
quarkus.oidc-client.grant.type=refresh
quarkus.oidc.authentication.extra-params.access_type=offline
quarkus.oidc.token.refresh-expired=true
quarkus.oidc.authentication.extra-params.prompt=consent

# Token State Manager Configuration
quarkus.redis.hosts=redis://localhost.com:17497
quarkus.redis.password=xxxxxxxxxxxxxx
quarkus.redis.max-pool-size=4

---

The Problem

My understanding is that this extension should create a session entry in Redis that holds the ID, access, and refresh tokens. When the access token expires, Quarkus should be able to use the stored refresh token to get a new one from Google automatically.

However, the entire Redis entry for the session seems to have a TTL (Time To Live) that matches the access token's expiration (e.g., 1 hour). When that hour is up, the key is deleted from Redis, taking the refresh token with it.

This forces the user to log in again, which is exactly what I'm trying to avoid.

---

My Question

Has anyone successfully configured this extension, particularly with Google as the provider?

1. Is there a specific configuration I'm missing that tells the extension to use the refresh token's expiration (which is typically very long or non-expiring) for the Redis entry's TTL?
2. Could this be an issue with how Google returns its tokens or a potential bug in the extension itself?
3. Is there a way to debug what the extension is receiving and writing to Redis to see why it's not picking up the correct expiration?

Any working examples or insights would be greatly appreciated. Thanks!

[quarkus-bot[bot]]

/cc @Ladicek (redis), @cescoffier (redis), @machi1990 (redis), @pedroigor (oidc), @sberyozkin (oidc)

[sberyozkin]

@Jaland thanks, I'll have a closer look next week, but it is definitely not the AT ttl that is used for a redis entry.

The TTL of this entry must be equal to the session's cookie max age which is a sum of the ID token ttl plus an optional session extension param, so it can be as large as needed.

You are also mixing in the quarkus-oidc-client config, it is unnecessary, quarkus-oidc refreshes tokens itself.

[sberyozkin]

Also CC Michal @michalvavrik

[sberyozkin]

@Jaland Can you check if the RT expiry is even returned by Google? I'm pretty sure it is a binary token.

I think your best try could be to extend the session max age with the quarkus oidc session extension property, for it to be equal to the rt ttl, to make sure that even if the user is idle and returns when the id token has already expired, the valid rt is still there to refresh tokens.
I suggest to make it work first without the redis manager and move to redis once all works as expected

[michalvavrik]

TTL is currently set to the session max age, so you should be able to leverage the quarkus.oidc.token.lifespan-grace configuration property. For the refresh token you can also use the quarkus.oidc.authentication.session-age-extension configuration property, which only takes effect when the quarkus.oidc.token.refresh-expired configuration property is set to true.

[michalvavrik]

updated my comment above since I didn't copy the property name properly from the all config page.

[sberyozkin]

For the default session manager, the session age extension is taken into the consideration.
We'll probably need to make sure db and redis ones do the same, I can have a look next week

[Jaland]

Hey y'all,

So it was quarkus.oidc.authentication.session-age-extension that I was missing. I know it defaults to 5 minutes but my client just showed it as 1h. Once I bumped it up to like 20000 and increased the TTL inside my Redis Cache to 6 hours.

Thanks for all the help late on a Friday

[sberyozkin]

Thanks @Jaland, let me mark your confirmation as an answer. I've checked the code, @michalvavrik already made sure the session max age is correctly used to calculate the life time of the Redis and DB entries

[Jaland]

Just adding this here for future folks, this is a little demo of using the redis cache:

https://github.com/Jaland/quarkus-oidc-redis-cache-example/tree/main