gitea should fail gracefully when OIDC IDP has problems

[cruwe]

First, thank you very much for developing gitea!

• Gitea version (or commit ref): db0d4ff
• Git version: v1.10.0-RC1, (I am sorry, I "destroyed" the test-case when fixing the issue, so I cannot test against more recent)
• Operating system: Ubuntu 18.04.3 LTS, 4.15.0-66-generic Refactor process package and introduce ProcessManager{} with tests #75-Ubuntu SMP, upstream Dockerfile
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

2019/11/12 07:36:17 ...uth/oauth2/oauth2.go:173:createProvider() [W] Failed to create OpenID Connect Provider with name '<...>' with url 'https://keycloak-management-infra.router.default.svc.cluster.local/auth/realms/<...>/.well-known/openid-configuration': Get https://keycloak-management-infra.router.default.svc.cluster.local/auth/realms/<...>/.well-known/openid-configuration: x509: certificate signed by unknown authority
2019/11/12 07:36:17 routers/init.go:92:GlobalInit() [F] Failed to initialize OAuth2 support: Get https://keycloak-management-infra.router.default.svc.cluster.local/auth/realms/<...>/.well-known/openid-configuration: x509: certificate signed by unknown authority

Description

When gitea has been configured against an OIDC IDP and when between restarts the IDP's endpoint stops being served with "proper/correct" certificates, gitea fails to start, running in a restart loop with a container built from the upstream Dockerfile.

Instead, I would like gitea to fail gracefully, disabling the IDP in question and allowing to login with other authentication sources (local admin comes to mind) to fix the problem "in app". I stumbled upon the issue when trying to "migrate" an instance over differently built experimental OpenShift clusters via the persistent volume. I "solved" the issue by deleting the corresponding row in "login_source" on the database.

The issue is minor, stems from operator weirdness in my case and is fixable. Abstracting from my specifics, however, I can imagine cases where a certificates' best-before-date may have been reached. I agree for various reasons that one should not trust such a certificate any more, especially for an IDP.
However, it would be nice to be able to fix such issues without reverting to fiddling with the database.

Thank you very much for your consideration! Cheers!

Screenshots

[lunny]

Maybe an option on Auth Source.

[xeals]

This is an ongoing issue and surfaces in more than just certificate issues.

I have a self-hosted instance of an OIDC provider (Keycloak) that occasionally fails for completely random reasons. Since it's behind a proxy, when it fails the proxy will return a plaintext "502 Bad Gateway" response, which Gitea happily tries to parse and brings itself down when it doesn't work.

2020/05/30 18:57:23 ...uth/oauth2/oauth2.go:174:createProvider() [W] Failed to create OpenID Connect Provider with name 'keycloak' with url 'https://keycloak.example.com/auth/realms/universe/.well-known/openid-configuration': invalid character 'B' after top-level value
2020/05/30 18:57:23 routers/init.go:142:GlobalInit() [F] Failed to initialize OAuth2 support: invalid character 'B' after top-level value
Received signal 15; terminating.

[kowalski7cc]

Yep, my personal keycloak failed and I have no time to fix it. So now I'm unable to use my gitea...

[kowalski7cc]

I worked it around by creating a new instance of keycloak on the same URL and deleting it from the settings page.

[netcicd]

I understand that this is a solution for some, but I can no longer re-enable keycloak. So in my case the cure is worse than the problem. Rebooting gitea in order to see if the connection does not help.

[zeripath]

@netcicd I don't understand. Why can't you re-enable keycloak?

[netcicd]

@zeripath thx for your rapid response. My monitor made the check-box invisible :) Can re-enable indeed this way (but this is hardly usable)
This implies that a user needs to log in as admin to get it working again. I use Keycloak and Gitea in Docker. Gitea boots faster than Keycloak and some form of retry /graceful recovery should be possible. I can imagine that you can configure a timeout as a solution: e.g. if Keycloak does not come back within say 5 min, only then disable. Or make it configurable.