System-wide OAuth2 Provider configured in app.ini #8345

New Issue

GiteaMirror · 2025-11-02T08:03:12-06:00

GiteaMirror commented

2025-11-02 08:03:12 -06:00

Originally created by @xyzroller on GitHub (Jan 12, 2022).

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/, https://github.com/go-gitea/gitea/pull/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

Originally created by @xyzroller on GitHub (Jan 12, 2022). ### 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/, https://github.com/go-gitea/gitea/pull/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_

GiteaMirror added the type/proposal label 2025-11-02 08:03:12 -06:00

GiteaMirror closed this issue

2025-11-02 08:03:12 -06:00

GiteaMirror commented

2025-11-02 08:03:12 -06:00

@h0tw1r3 commented on GitHub (Feb 6, 2023):

#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.

@h0tw1r3 commented on GitHub (Feb 6, 2023): #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.

GiteaMirror commented

2025-11-02 08:03:13 -06:00

@wxiaoguang commented on GitHub (Feb 6, 2023):

I think this issue has been fixed by #21335

@wxiaoguang commented on GitHub (Feb 6, 2023): I think this issue has been fixed by #21335

GiteaMirror commented

2025-11-02 08:03:13 -06:00

@delvh commented on GitHub (Feb 6, 2023):

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?

@delvh commented on GitHub (Feb 6, 2023): 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?

GiteaMirror commented

2025-11-02 08:03:13 -06:00

@xyzroller commented on GitHub (Feb 9, 2023):

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.

@xyzroller commented on GitHub (Feb 9, 2023): 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.

GiteaMirror commented

2025-11-02 08:03:13 -06:00

@h0tw1r3 commented on GitHub (Feb 22, 2023):

@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?

@h0tw1r3 commented on GitHub (Feb 22, 2023): @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?

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#8345