Struggling with access token refresh after timeout, with SPA

[qpkorr]

Hi,

First - thanks very much for your module, it works great (when I drive it correctly!)

I've got an SPA using apache (2.4.52), your module (2.4.9.4) and Azure AD as identity provider.
On initial page load, everything works perfectly - meaning
a) the main page loads, redirects, authenticates, etc
b) various XHR GETs all work, via the same authenticated path
c) saving data with PUTs works too.

After something times out though, when a PUT is requested, it fails, gets redirected, and then I hit a CORS error trying to authenticate it as Azure AD hasn't provided Access Control headers to allow it.
I've seen some suggestions that I need to configure Azure to know it's an SPA, to get it to add appropriate Access Control headers - but when I do that, Azure won't let me log in at all - complaining (IIRC) the it needs PKCE, which I tried enabling with all three OIDCPKCEMethod settings but Azure was never happy.

So - I'm trying a different path. The PUT works initially. So my current attempt (there's been a few, eg setting OIDCRefreshAccessTokenBeforeExpiry so that I'd never see any issues with timeouts - not sure why this didn't work for me) is to detect when the PUT fails, then send to
<redirect_uri>?refresh=<return_to>&access_token=<access_token>
to refresh the access token, then try my PUT again.
The problem is, I'm getting
oidc_handle_refresh_token_request: no existing access_token found in the session, nothing to refresh

The session key seems to be correct, but it's getting a cache miss.
The config I'm changing is I think limited to:
OIDCProviderMetadataURL https://login.microsoftonline.com/XXXXX/v2.0/.well-known/openid-configuration
OIDCClientID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
OIDCClientSecret XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
OIDCRedirectURI https://XXXXX.XXXXX.XXX/${customername}/${customerservice}/auth/redirect
OIDCCryptoPassphrase XXXXXXXXXXXXXXXXXXXXXXXXX
OIDCSessionMaxDuration 864000
OIDCSessionInactivityTimeout 10
OIDCCookie rta_openidc_session
OIDCScope "openid email profile offline_access"
OIDCRemoteUserClaim preferred_username
OIDCPassRefreshToken On
OIDCPassClaimsAs both
OIDCRefreshAccessTokenBeforeExpiry 10
OIDCInfoHook access_token id_token

And here's the logs I presume to be relevant - hopefully the redaction hasn't obscured anything:
access_token_refresh.log.gz

Thanks very much for any help you can offer,
John

PS I think I've found similar discussions - but "extend the timeouts" was sometimes the main solution, which doesn't feel right to me.

[zandbelt]

it seems that the session expires, not the access token, hence refreshing the access token fails because the session is gone

the XHR/PUT request should not lead to a redirect: either protect it explicitly with AuthType auth20 or AuthType auth-openidc, or - better - use the latest version of mod_auth_openidc which has an improved auto-detection mechanism for non-browser requests; this will return 401 on the XHR/PUT instead of redirecting (which would never return if the user needs to explicitly authenticate)

after receiving the 401 the SPA needs to trigger a full authentication roundtrip i.e. by refreshing the parent window

[qpkorr]

Thanks very much Hans for the quick response.

Yes, that makes sense that it's the session expiring in terms of the error I'm seeing (I was looking at the source code and decided this was the case). I'm a bit confused about why it's happening, given, in the log I provided, we see these two lines:
[Fri Aug 26 21:51:02.872658 2022] [auth_openidc:debug] [pid 19067:tid 140085508953856] src/mod_auth_openidc.c(866): [client 127.0.0.1:49378] oidc_log_session_expires: session max lifetime: Mon, 05 Sep 2022 11:50:52 GMT (in 863989 secs from now), referer: https://XXXX-stage.XXXX.net/customer/rtas/
[Fri Aug 26 21:51:02.873478 2022] [auth_openidc:debug] [pid 19067:tid 140085508953856] src/mod_auth_openidc.c(866): [client 127.0.0.1:49378] oidc_log_session_expires: session inactivity timeout: Fri, 26 Aug 2022 11:51:12 GMT (in 9 secs from now), referer: https://XXXX-stage.XXXX.net/customer/rtas/

I'd thought that when the inactivity timeout happened (after 10 seconds), I had up until the session max lifetime (10 days) to be able to refresh using the refresh token - but that's not the case?

Re the 401 - I guess the problem is that a user a) loads the page, b) starts editing stuff, thinking, editing - has their changes ready to go and wants to c) go save (PUT) them - so I want that save mechanism to work reliably. It's possible there's a significant time delay between a) and b) too. Refreshing the parent window (as things stand now) will lose the changes they've just made. Hence my attempt to automatically re-authenticate on failure, using the refresh token, then try the save (PUT) again. Are you saying there's no way to reliably reauthenticate and retry the save - even if I set the SessionMaxDuration to be huge, despite that being, as best I can tell, what the user probably wants (short of somehow passing the save data to the parent window again)?

[zandbelt]

it looks like you want to set OIDCSessionInactivityTimeout to a larger value

[qpkorr]

Yes, it's set intentionally small for testing purposes. Originally I used the default values, but users complained about saves not working sometimes. I suppose there's little effective difference between automatic refreshes and long timeouts.

I guess my hope was that the XHR PUT could, when appropriate, trigger a full reauthentication round trip (with user interaction), after which the PUT could run and succeed, honoring the user's intentions (they didn't request a full page load, they just asked to save their work).
Is there a reason why that's an unreasonable hope/expectation? Apologies if that seems a stupid question to an expert like yourself!

[zandbelt]

it is a security sensitive case: after the timeout someone else could takeover the terminal and "see" the original user's PUT data; IMHO it shifts the problem and does not actually comply with the short timeout that you want to apply, so better change the timeout

[qpkorr]

Sorry for the delay, been sick - thanks Hans, fair enough I suppose. Perhaps what I really should be doing is setting a timer in my SPA such that when my authentication expires, it prompts to reload the page - hopefully before a user goes and makes changes they then wish to save.

[opoplawski]

I'm running into the same situation - we have a Mediawiki instance protected by mod_auth_openidc. The user starts editing a page and if they submit their changes after the timeout occurs the edits are lost because the PUT fails. This is a pretty bad user experience. I can bump OIDCSessionInactivityTimeout but this only partially works around the issue.

Does https://github.com/zmartzone/mod_auth_openidc/wiki/OpenID-Connect-Session-Management have any bearing on this issue? I tried adding that to our pages, but it doesn't appear to help. I'm seeing 404's in the logs for the URLs I added:

"GET /protected/redirect_uri?session=iframe_op HTTP/1.1" 404 196
"GET /protected/redirect_uri?session=iframe_rp HTTP/1.1" 404 196

I suppose another idea would be to add an edit countown timer to the page to warn a user that their session is about to expire. Does mod_auth_openidc have any method for that? Should it?

Otherwise, thanks for a great module, it's very helpful.

[qpkorr]

Yes, I'm planning to add a countdown timer but haven't got there yet. The silliest thing to me is the inconsistency - a GET request will happily go off to the authenticating server and refresh things in the background - but a PUT request (or preflight check) will just fail. So it's not like any risk is being reduced - for my pages at least, a failed PUT just means a user just has to click a link that triggers a GET, then the PUT will work fine again, with no re-entering of credentials - which is why this feels so much like a bug to me, not a feature?

Also - in one of my pages that hits this problem, the PUT is actually trying to change stuff - but in the other, it's simply used for as-you-type suggestions in a search bar - so the PUT (that fails) is no more dangerous than the GETs (which succeed).

[zandbelt]

most likely you're using an older version, the GET request should also fail for SPAs because XHR requests cannot (should not) be used to authenticate users since authentication requires a full browser context, excluding iframes/background

[qpkorr]

Hmm - two versions actually - 2.4.9.4-0+deb11u1 but also 2.3.10.2-1+deb10u1. Better fix that!
My understanding (which is not as good as I'd like alas) was that there's two levels of auth going on - there's the level of auth where you need to enter full credentials, then there's a lower level, where that's not required. The point of the lower level is that if the user's permissions have been revoked on the IDP, the web page won't know unless it checks. It's this low level check which should be able to happen automatically in the background - and does for me with GETs - but doesn't with PUTs. I think this is refreshing the access token - but I could be wrong

[zandbelt]

no, there's only one level and it needs to be in a full browser because your IDP session may be gone and authentication may be necessary; there's an OpenID Connect feature that allows you to check whether the IDP session still exists but that is different and would not solve your problem since then the problem would shifted to the IDP session timeout

if you want to avoid timeouts (regardless of HTTP method), increase the inactivity timeout, or keep the session alive as described above, that's all

[qpkorr]

Thanks. By the way you're right - the GET requests I was referring to were clicks in the browser, not XHR requests.
You say "if you want to avoid timeouts (regardless of HTTP method), increase the inactivity timeout". I'd already set it to 5.5 days via:
OIDCSessionInactivityTimeout 475200
OIDCSessionMaxDuration 0
but was still getting these failures about once an hour, which is why I figured it was the access token timing out (as Azure issues it for 60-90 minutes by default). I changed the access token timeout in Azure to one day (max they will allow) and that appears to have worked. I'm currently wondering whether to bother trying to fetch the info hook on a timer - since that, presumably, would be no more effective for me than setting OIDCSessionInactivityTimeout?

Update: gah, I don't know. I thought my access token timeout was extended, and users reported improved behaviour - but the OIDC_access_token_expires variable suggests it wasn't extended.

A question therefore: if OIDC_access_token_expires is 3600 seconds from now, and oidc_log_session_expires is 475200 seconds from now - the former will trigger a re-auth round trip, regardless of the latter - correct?

[zandbelt]

see also here:
https://github.com/zmartzone/mod_auth_openidc/wiki/Sessions-and-Timeouts