Current Behavior
If the upstream provider redirects to apisix with a standard OAuth2 error response apisix will return a 500 error. Most of the error codes will end up being caused by some kind of misconfiguration, but the temporarily_unavailable code can occur when everything is nominal.
One example we've run into is that when Keycloak's login attempt expires, it redirects back to apisix with ?error=temporarily_unavailable&error_description=authentication_expired and this login attempt could be automatically retried.
Expected Behavior
It would be ideal to at least handle the temporarily_unavailable code, the others are probably fine as-is. For this code I think it's reasonable to reattempt the authentication.
I was able to generate a plausible looking fix for this with Claude Code, I've spent a fair amount of time reading the openid-connect sources while dealing with shaking out bugs in our configuration so I have high confidence in the fix itself, the tests are a different matter because they look a bit verbose to my eyes. I've pushed this up to our fork here: mitodl@4387527
Happy to collaborate on getting this to a mergable state if that looks like it's in the right direction.
Error Logs
openid-connect.lua:876: phase_func(): OIDC authentication failed: unhandled request to the redirect_uri: /login/.apisix/redirect?error=temporarily_unavailable&error_description=authentication_expired&state=...&iss=...
Steps to Reproduce
- Run APISIX configured with the openid-connect plugin against a provider like Keycloak.
- Attempt to login, but allow the login attempt to timeout (setting a low timeout helps make this happen faster).
- Continue to login after the timeout has elapsed and get redirected to APISIX and hit the 500 error.
Environment
- APISIX version (run
apisix version): 3.17.0
- Operating system (run
uname -a): Linux apache-apisix-dc84694c8-2h8xc 6.18.38-76.139.amzn2023.x86_64 #2 SMP PREEMPT_DYNAMIC Fri Jul 24 13:38:05 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
- OpenResty / Nginx version (run
openresty -V or nginx -V): openresty/1.29.2.4
Current Behavior
If the upstream provider redirects to apisix with a standard OAuth2 error response apisix will return a 500 error. Most of the error codes will end up being caused by some kind of misconfiguration, but the
temporarily_unavailablecode can occur when everything is nominal.One example we've run into is that when Keycloak's login attempt expires, it redirects back to apisix with
?error=temporarily_unavailable&error_description=authentication_expiredand this login attempt could be automatically retried.Expected Behavior
It would be ideal to at least handle the
temporarily_unavailablecode, the others are probably fine as-is. For this code I think it's reasonable to reattempt the authentication.I was able to generate a plausible looking fix for this with Claude Code, I've spent a fair amount of time reading the openid-connect sources while dealing with shaking out bugs in our configuration so I have high confidence in the fix itself, the tests are a different matter because they look a bit verbose to my eyes. I've pushed this up to our fork here: mitodl@4387527
Happy to collaborate on getting this to a mergable state if that looks like it's in the right direction.
Error Logs
Steps to Reproduce
Environment
apisix version): 3.17.0uname -a):Linux apache-apisix-dc84694c8-2h8xc 6.18.38-76.139.amzn2023.x86_64 #2 SMP PREEMPT_DYNAMIC Fri Jul 24 13:38:05 UTC 2026 x86_64 x86_64 x86_64 GNU/Linuxopenresty -Vornginx -V): openresty/1.29.2.4