System-wide OAuth2 Provider configured in app.ini

[xyzroller]

Feature Description

Feature Request Summary

As a Gitea administrator, I would like to configure a system-wide OAuth2 provider via app.ini so that I can configure Gitea at deployment time to be a simple IdP for a small number of other applications.

Feature Request in a bit more detail

Currently, Gitea has the capability of being a simple OAuth2 provider (https://docs.gitea.io/en-us/oauth2-provider/, #14139). This works very nicely to set up a collaboration platform (e.g. Gitea + Matrix) for a small team/organisation.

However, in order for this to work, Gitea needs to be deployed and then some user needs to set up an OAuth2 application in their user settings, which generates a Client ID and Client Secret for another application that will use Gitea for login.

This makes automating the deployment of Gitea with other applications quite complicated as the deployment needs to be sequenced with various CLI / API calls to Gitea -- e.g. deploy Gitea, then create a Gitea user via CLI or API, then add an OAuth2 application to the user's account via API, receive Client ID and Client Secret, pass these to the next application deployment, then deploy the next application.

Much easier would be to configure a system-wide OAuth2 provider via app.ini with a pre-defined Client ID and Client Secret as parameters, for example:

[oauth2]
ENABLE = true
...
GLOBAL_OAUTH2_NAME = "<Some name>"
GLOBAL_OAUTH2_REDIRECT_URL = "<Callback URL>"
GLOBAL_OAUTH2_CLIENT_ID = "<some client ID>"
GLOBAL_OAUTH2_CLIENT_SECRET = "<some client secret>"

What the Feature Request is not requesting

The Feature Request is not asking for more IdP, IAM or SSO functionality beyond that which is already implemented. It is not the intention for Gitea to turn into something like Keycloak.

Screenshots

No response

[h0tw1r3]

#14808 doesn't directly meet the requirements, but does provide a way to create authentication sources through the api, which could be done on install / setup.

[wxiaoguang]

I think this issue has been fixed by #21335

[delvh]

Yeah, I think the configured in app.ini part is negligible here if you can set it up from the UI.
Unless of course there's an explicit need for it?

[xyzroller]

The idea was to be able to set up the system wide OAuth2 provider in configuration, so that Gitea container images could be built with this configuration during automated build processes, or pull the configuration at container launch time. Post-configuration after container launch (either manual, or via API) doesn't fit the model I was trying to achieve. If a container needs to be replaced by the automation process, e.g. stopping in one cluster and starting in another, then requiring a post-launch configuration complicates the automation significantly.

[h0tw1r3]

@xyzroller I think I understand your deployment scenario. Wouldn't the API still be effective if as part of the build you started the service listening on a local address (not accessible by the load balancer), configured everything via API, then restart with listening normally?