Open edubonifs opened 1 year ago
As an update about this issue, we found the parameter: discoveryPollInterval -> The interval at which OIDC configuration is discovered at /.well-known/openid-configuration If not specified, the default value is 30 minutes.
So with this parameter we are able to refresh the OIDC configuration. However the customer would like to distinguish between ExtAuth not being able to fetch OIDC because of errors, and ExtAuth refetching the configuration.
So they think this parameter is good when you change the OIDC configuration and want ExtAuth to refresh, but they think 30 minutes by default is too long to wait if an error is produced because not being able to fetch the config and should be treated in a different way.
This issue has been marked as stale because of no activity in the last 180 days. It will be closed in the next 180 days unless it is tagged "no stalebot" or other activity occurs.
This is still an issue.
Gloo Edge Version
1.14.x (latest stable)
Kubernetes Version
None
Describe the bug
I am using OIDC with Gloo Edge, for one of our customers .well-known/openid-configuration endpoint is not available during the ExtAuth pod startup. It seems extauth does not recover from this anymore, so the only workaround is to restart extauth. Then everything is working fine again.
Steps to reproduce the bug
These are the steps used to reproduce the issue (the authserver is providing the OAuth endpoints, including .well-known/openid-configuration):
This is the example AuthConfig:
Here are the logs for Gloo 1.14:
Expected Behavior
ExtAuth should be able to refetch the .well-known/openid-configuration endpoint
Additional Context
No response