Replies: 3 comments
-
this is expected behaviour; since the userinfo claims cannot be refreshed, those claims are removed from the session and subsequent authorization based on those claims will fail with a 401; you could change that behaviour with |
Beta Was this translation helpful? Give feedback.
-
I do realize that there's room for additional options since the access token error happens before the authorization phase, in the authentication phase where it is still possible to reauthenticate the user; so I added e7d85e7 which allows you to use OIDCUserInfoRefreshInterval 60 authenticate_on_error to achieve the behaviour that you are looking for |
Beta Was this translation helpful? Give feedback.
-
Thank you for the quick reply and the helpful suggestions! As you proposed I added |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everybody,
I'm experiencing a problem with mod_auth_openidc (2.4.14.2) in combination with Keycloak (21.1.2). I can reproduce the problem with the following steps:
I attached a debug log below that shows that the module tries to refresh the claims from the user info endpoint and receives status code 401. Then it tries to refresh the access token with the refresh token and receives status code 400 as the Keycloak session is no longer active. To me it looks like the module does not handle the response of that second request properly.
My question now is, are my expectations regarding the redirection of the user wrong at this point or is there an issue with my configuration or the module?
My mod_auth_openidc apache configuration (replaced some sensitive values):
Log messages during of mod_auth_openidc module with level "debug" (replaced some sensitive values):
mod_auth_openidc_debug.log
Beta Was this translation helpful? Give feedback.
All reactions