Google refresh token, consent prompt, and sessions

[therealchjones]

First, @zandbelt, thanks so much for all your hard work on this. I've found the documentation easy to read and the configuration relatively straightforward.

Unfortunately, I've had some difficulty creating the user experience I'd like. I don't think it's unusual, but I haven't been able to get it right, and hope others here might have some tips (or at least pointers on where else to look). It boils down to a couple of issues:

• Apparently Google (my OP) will only send a refresh token if the consent prompt is part of the auth flow, even if the user has previously consented
• It appears mod_auth_openidc stores the refresh token as part of the session cache

Thus, every time a session ends, not only does the user need to re-authorize, they're also required to click through the consent prompt once more. This has not been my experience as a user, when I expect to receive the consent prompt the first time I use an app and then only if I explicitly revoke app access, whereas the "login" without the consent prompt may be considerably more often.

Can anyone share if they've figured out how to maintain a refresh token from Google over multiple sessions, or otherwise avoid frequently having users re-consent?

Thanks again, everyone!

[therealchjones]

The annotated relevant directives from my current configuration (which does not solve the above problem). (Other settings for using Google as OP are removed, <domain> is redacted):

  # Google doesn't use the 'offline' or 'offline_access' scope recommended by OpenIDC
  OIDCScope "openid https://www.googleapis.com/auth/userinfo.email"
  # prompt=consent forces the consent screen on each login request---but if we don't use the consent
  # screen, we don't get a refresh token with the access token
  OIDCAuthRequestParams "hd=<domain>&access_type=offline&prompt=consent"
  # max mod_auth_openidc session length 2 weeks
  OIDCSessionMaxDuration 1209600
  # max mod_auth_openidc session inactivity 2 weeks (effectively, don't time out due to inactivity)
  OIDCSessionInactivityTimeout 1209600
  # refresh access token 4 minutes before expiration if the user happens to be actively using the app then
  # (this is seldom needed in practice; Google access tokens typically have an expiration time of 1h and the 
  # OIDCUserInfoRefreshInterval refreshes every 30 minutes)
  OIDCRefreshAccessTokenBeforeExpiry 240
  # refresh access +/- refresh token as needed every 30 min even if no user activity
  OIDCUserInfoRefreshInterval 1800
  # Allow sessions to persist post browser restart
  OIDCSessionType server-cache:persistent
  # Allow sessions to persist past server restart
  OIDCCacheType file

The issue remains that whenever the mod_auth_openidc session ends, the refresh token is removed from mod_auth_openidc's cache, and another must be obtained if access token expiration length is not sufficient for a session. Access token expiration time for Google OAuth is typically 1 hour; I believe logging in every hour to be a poor user experience, so I don't consider that sufficient. However, obtaining a new refresh token appears to only be possible by having the user go through the "new user" flow including the consent screen. I can only assume that Google expects the refresh token to be stored indefinitely and reused for the same user during different sessions.

The only idea I have for doing this without modifying mod_auth_openidc would be modifying my backend app to store the refresh token (in some form) within a user database and "re-inject" this into the mod_auth_openidc cache after a new session is created for the user. This sounds suboptimal, and I'll admit I haven't tried it yet. I'd love to hear any recommendations for other methods, or how any of you handle this issue.

Thanks again, everyone!

[zandbelt]

what would you need the refresh token and access token for?

[therealchjones]

I use the access token (with more scopes than shown than shown in this testing/debugging scenario I put together here) to access the user's Google Drive and some Google Workspace admin tools. (Scopes: https://www.googleapis.com/auth/drive and several https://www.googleapis.com/auth/admin.*) I typically use a setup like that in the SPA wiki article to send API requests from the backend using the OIDC environment variables rather than passing the tokens to the browser. In my case, I don't actually need true "offline" access when the user is away from the keyboard, but am primarily using it to try to mitigate their needing to log in several times each day when the access token expires. The best balance I've found between "more secure" and "more convenient" is with frequently (autonomously) checking the userinfo endpoint to ensure consent hasn't been revoked and timing out the mod_auth_openidc session after several days. However, when that session does expire, I again have to prompt the user for consent rather than using the "returning user" login flow. The alternative is forgoing the consent screen, and therefore the refresh token, and therefore having the user login every time the access token expires---which several users would be doing several times each day.

Of course, I'm more than happy to change any of that configuration if I've misunderstood a flow or something else works better!

[zandbelt]

what about not requiring a refresh token and send the user through an authentication roundtrip - which would happen without consent or explicit authentication - whenever the access token has expired

[therealchjones]

Well, this is fantastic. Somehow I missed this possibility; this is clearly the perfect use case for a silent roundtrip reauthentication. I haven't tested it yet but it looks like just what I'll need. I'll check back in and post an "answer" once I get the kinks worked out. Thanks so much again!

[therealchjones]

Thanks very much again for your assistance, @zandbelt. Unfortunately, I've had poor luck implementing this in a way transparent to the users. I can redirect the interactive login for users to attempt silent reauthentication through the browser (which, as expected, redirects a couple of times but doesn't require the user to interact further), but haven't managed to do this without user initiation.

Specifically, if the user is authenticated and authorized, with a valid access (and ID) token, but is actively using the app when the access token expires, the app cannot go through a round-trip without interrupting the user. (At least, I haven't come up with a way to do so.) I've attempted to simply fetch() an appropriately protected Apache resource, and I've attempted to similarly load a resource in a hidden iframe, but have failed with iframe or CORS errors (presumably because the OP is blocking those methods of accessing the authentication endpoint).

Despite the excellent options available in mod_auth_openidc (I've now had the opportunity to work with OIDCPathAuthRequestParams, UnAuthAction, and the cool auth request # parameter replacement), I'm afraid I'm back to being unable to keep an up-to-date access or ID token without suboptimal user interaction (either frequent logins/interruptions or repeated consent screens). I'd love to see what some of the bigger apps/sites have come up with in this arena. I really appreciate your time, Hans, but if you or anyone else has other ideas I'd love to hear them. I fear I may have to switch to something Google-branded for the user appreciation factor even if it's not as pleasant on the back end.

Thanks again,