getting http 401 after having been authenticated already

[shayannyc25]

hi
i am using the mod auth oidc to protect the service side of a web app. Here is how we configured our mod auth oidc and how we understood mod auth oidc will behave.

• The ui and service are hosted on different domains , i.e ui.x.com, and service.y.com. The service is in java (or could be other language) and is fronted by apache web server with mod auth oidc plugin enabled and apache web server just proxies the call to the service. We have configured the apache web server in the service to allow cors access from the ui domain.

• We are using Ping Federate for our auth provider with "oauth auth code flow". Our Ping Federate is configured to NOT allow calls to its auth end point via xhr (as doing so will prevent user from seeing any html returned by Ping Federate in xhr call) and only allows calls to the auth end point via regular java script calls so that end user can interact with Ping Federate (i.e provide user name/password via a html form) via the browser only.

• Our Ping Federate doesn't return refresh tokens for the auth code flow and only returns access token and expects the user to be reauthenticated with Ping Federate after jwt access has expired. The access token is valid for couple hours max.

• Due to a bug in version 2.4.11.2 , we had to internally patch it till it was publicly fixed

• We had configured our mod auth oidc to expose the user's claims (userinfo object) and access token expiration (access_token_expires) and id token (id_token) in the mod auth oidc's user info hook ( OIDCInfoHook = iat access_token_expires id_token userinfo session )

• We use Chrome and Microsoft Edge for our browsers

• The ui usually calls the service via xhr calls and assumption is that mod auth odic will intercept the call to protect the service and if the user is not authenticated , mod auth oidc redirects the user to our auth provider's auth end point and then once authentication is done, our auth provider redirects the user to to the redirect url of the service provided during the registration with the auth provider and a code is passed to the redirect url and then mod auth oidc takes the code and calls the auth provider to exchange the code with a jwt access token and then calls the auth provider user info end point to get some additional claims using the jwt access token and stores the jwt access token and those additional claims in a encrypted browser side cookie.

• Cause of the above mentioned set of our Ping Federate, we had to create a java script library that would call the user info end point exposed by the mod auth oidc on the service (OIDCRedirectURI?info=json) to get the access token expiration time (access_token_expires) and set a timer so that just right after the token has expired, the library redirect the user via regular java script call (no xhr call) to some special end point (mod auth oidc protect) that we created in the service to kick of the authentication flow. Mod auth odic would intercept the call as the access token has expired or user was never authenticated and then redirect the user to Ping Federate auth end point and once auth flow is done, the call is sent to the service and the service simply forwards the user back to the landing page of the ui app. Again the reason for doing this is if dont the above and the access token has expired already, then when the ui makes a call to the service using xhr and mod auth odic intercepts the call and redirects the user to the Ping Federate auth end point, user will get cors error as our Ping Federate doesen't allow access to its auth end point via xhr calls and only allows access to the auth point using html form or
  using java script document.location to send the user to the auth end point.

• Here is the problem that we are running into for scenario one. Assume that we had set OIDCSessionInactivityTimeout to 300 and OIDCSessionMaxDuration to 0 (to indicate that mod auth oidc session duration should be that of access token expiry time) . The first time the user access the ui , our library calls the user info end point of mod auth oidc and gets a 401 as expected and then the library via html form or java script document.location sends the user to service.y.com/userAuthEndPoint. Mod auth oidc intercepts the call, and redirects the user to Ping Federate auth end point and Ping sends back a code to the redirect url of our app , which mod auth oidc takes and exchanges with access token and stores in cookie. Our js library next calls the user info end point of mod auth oidc of our service ervice.y.com/userinfo?info=json and gets the users claims and also finds out when token is expiring. Now lets say the access token is only good for 1 hour and our js library right after 1 hour sends the user via html form or java script document.location to service.y.com/userAuthEndPoint and again mod auth oidc intercepts the call, redirects the usr to the Ping Federate auth end point and etc and gets a new access token , so now our user is reauthenticated and has a new access token with an expiration time of 1 hour from now (and library again calls service ervice.y.com/userinfo?info=json and gets the new token expiration time and claims) . Now if the ui calls some end point in the service , i.e service ervice.y.com/api/shipments/1111 , via xhr , we are getting a http 401 even though the user was already authenticated. Also if we call the service ervice.y.com/userinfo?info=json via browser address bar we also get http 401. Not sure why this is happening as the user as already authenticated. If we call service ervice.y.com/api/shipments/1111 via browser address bar, mod auth oidc intercepts the call and redirects us to the Ping Federate auth end point and then the call to service ervice.y.com/api/shipments/1111 goes through.

• Here is a problem that we ran into for scenario 2. Assume that we had set OIDCSessionInactivityTimeout to 28800 and OIDCSessionMaxDuration to 28800 . The first time the user access the ui , our library calls the user info end point of mod auth oidc and gets a 401 as expected and then the library via html form or java script document.location sends the user to service.y.com/userAuthEndPoint. Mod auth oidc intercepts the call, and redirects the user to Ping Federate auth end point and Ping sends back a code to the redirect url of our app , which mod auth oidc takes and exchanges with access token and stores in cookie. Our js library next calls the user info end point of mod auth oidc of our service ervice.y.com/userinfo?info=json and gets the users claims and also finds out when the new token is expiring. Now lets say the access token is only good for 1 hour and our js library right after 1 hour sends the user via html form or java script document.location to service.y.com/userAuthEndPoint and again mod auth oidc intercepts the call, redirects the user to the Ping Federate auth end point to get a new access token , so now our user is reauthenticated and has a new access token with an expiration time of 1 hour from now . Our js library again calls service user info end point service.y.com/userinfo?info=json to get the new token expiration time and claims, however the access token returned by the user info end point is the old one , not the new one , and has the expiration time of the 1st access token, not expiration time of the new token. This is not caching issue as we had make sure the call to service.y.com/userinfo?info=json wasnt cached. So it seems that service.y.com/userinfo?info=json is not returning the new access token and instead returning the original/fist access token only.

• Below is the config file of my mod auth oidc:
  LoadModule auth_openidc_module /ms/dist/webinfra/PROJ/mod_auth_openidc/2.4.11.2-mspatch/.exec/x86_64.linux.2.6.glibc.2.17/lib/mod_auth_openidc-oss-g.so

   OIDCResponseType "code"
  
   OIDCRedirectURI /oidc/cb
  
   OIDCPKCEMethod S256
  
   OIDCSSLValidateServer On
  
   OIDCOAuthSSLValidateServer On
  
   OIDCScope "openid profile"
  
   OIDCCookie <some cookie name>
  
   OIDCCookieHTTPOnly On
  
   OIDCCookieSameSite Off
  
   OIDCStateMaxNumberOfCookies 5 true
  
   OIDCSessionInactivityTimeout 300
  
   OIDCSessionMaxDuration 0
  
  OIDCSessionType client-cookie
  
   OIDCRemoteUserClaim <some claim name>
  
   OIDCOAuthRemoteUserClaim <some claim name>
  
   OIDCOAuthRemoteUserClaim <some claim name>
  
   OIDCPreservePost Off
  
   OIDCPassClaimsAs both
  
   OIDCCacheEncrypt On
  
   OIDCClaimPrefix <someheader>
  
   OIDCPassUserInfoAs json
  
   OIDCOAuthVerifyJwksUri <someurl>
  
   OIDCPassIDTokenAs payload
  
   OIDCInfoHook iat access_token_expires id_token userinfo session
  
   OIDCXForwardedHeaders X-Forwarded-Proto
  
   OIDCClientID <someid>
  
  OIDCProviderMetadataURL <some url>
  

  OIDCPrivateKeyFiles

  OIDCProviderTokenEndpointAuth private_key_jwt

  OIDCCryptoPassphrase

[zandbelt]

Please provide the full server debug logs to analyze; one thing that stands out in your config is:

OIDCInfoHook iat access_token_expires id_token userinfo session

which does not actually return an access_token from the info hook, just the expiry time and the id_token which will not work because the id_token is not stored in the session because of size limitiations when using OIDCCacheType client-cookie.

so the provide config does not match the described behavior

[shayannyc25]

@zandbelt hi, thanks for quick reply. we dont expose the access token in the user info hook. The user info hook does expose the id token as configured. Below is snippet (the session info object is cut off in the picture) of the json that is returned by the user info end point service.y.com/oidc/cb?info=json
.

I had added LogLevel auth_openidc:debug in the mod auth odic config file but handt seen anything useful. My apache error logs had been delted since i had posted this and I will try to generate fresh debug logs for the module and send you. Below is what i have so far but need to wait till access token expires to reproduce the issue and will then send you new debug logs.

[zandbelt]

I'm sorry but the amount and the inconsistency in information that you present makes it impossible to say anything useful for me (also, pictures of logfiles are never a good idea...) ; this also leads me to believe that there's some misunderstanding going on here, rather than something that does not work; I'll leave it at this, maybe someone else can chime in

[shayannyc25]

@zandbelt sorry if i am not clear. please let me know which parts are not clear. Due to security policy , i am not able to send actual log files. The reason we implemented our own js library was that since we can not get a refresh token from Ping Federate, the ui app could not initiate the access token refresh (as described in https://github.com/zmartzone/mod_auth_openidc/wiki/Access-Tokens-and-Refresh-Tokens) by calling <redirect_uri>?refresh=<return_to>&access_token=<access_token> as that requires that we get refresh token and that refresh token be stored in the cookie. So as a work around, we were hoping that if we wait long enough for the access token to expire and then call some protected path/end point in the service, then mod auth oidc will see that access token is expired and will redirect the user to the Ping Federate auth end point to reauthenticate the user and then save the new access token in the cookie. However as mentioned above, after the reauthentication is done , the user info end point /oidc/cb?info=json is still returning back the expiration time of the old access token (access_token_expires element ). Not sure why the user info end point is not returning the expiration time of the new access token.
i also had read https://github.com/zmartzone/mod_auth_openidc/wiki/Single-Page-Applications.
Since we dont get the refresh token, we cant use OIDCUserInfoRefreshInterval property to auto refresh the user info claims. Not sure if OIDCUserInfoRefreshInterval will also auto refresh the access token as well or not. Also we can not use OIDCRefreshAccessTokenBeforeExpiry to auto renew the access token before its expiry in mod auth oidc modue itself as this also requires refresh token. We also cant manually kick of refresh of access token by calling <redirect_uri>?info=json&access_token_refresh_interval= as this also requires refresh token.

thanks lot

[zandbelt]

I suggest getting commercial support via sales@zmartzone.eu