[Bug]: When OIDC provider is responding with an error message other than 4XX on renew, the session is lost

[doktormerlin]

Version

13.1.0

Please provide a link to a minimal reproduction of the bug

No response

Please provide the exception or error you saw

On a renew (silent or forced) the session tokens get deleted in case of any error. This can result in sessions getting invalidated even when they should not be invalidated (e.g. in case of Proxy problems).

Steps to reproduce the behavior

1. Use a setup with the OIDC provider behind a proxy
2. Get an access_token by logging in as usual
3. Reconfigure the proxy so that the OIDC provider is not accessible anymore
4. Wait until the next silent_renew. The token gets deleted from the session storage even though it should be still valid

A clear and concise description of what you expected to happen.

The correct behaviour in my opinion should be, to not delete the token unless the access_token is expired or the OIDC provider responds with a 4XX error code (maybe this could even be restricted further to 401 and 403)

It is very possible that a token is still valid and can be validated by the backend even if the OIDC provider is not accessible from the frontend.

The best solution IMO would be to allow an array of Status Codes on which the tokens should be deleted/invalidated.

Additional context

While I set the version to 13.1.0 but looking at the Code it looks like it is still present in 16.0.0.

[joewIST]

Also experiencing this issue. Any luck resolving it?

[doktormerlin]

Also experiencing this issue. Any luck resolving it?

Sadly not. We circumvented it by making our OIDC prodiver as highly available as possible. Thanks to this, the users do not get the issue anymore, but it comes at a high cost for infrastructure. I am planning to create a fork and Pull-Request at some point to mitigate the issue, but this task is deep in the backlog