[Thread] SSO Auth Tracking #10551

Open
opened 2025-11-02 09:11:02 -06:00 by GiteaMirror · 7 comments
Owner

Originally created by @kdumontnu on GitHub (Mar 29, 2023).

Feature Description

External auth was initially implemented in gitea with the intention of providing an alternate, parallel method for user login to cloud services (eg. GitHub, OpenID, etc.), and has subsequently been extended to include enterprise services, like Azure AD, Okta, etc.

There are a number of issues in the current implementation that don't work when configuring gitea for integration with a single sign-on tool for provisioning users with access control. These range from quality of life to potential security issues if not properly mitigated. Some of these already have associated issues/PRs, but some do not. The goal here should be to enable Gitea accounts to be fully managed from an external auth provider, which is a requirement for most enterprise applications.

This issue serves as a tracking thread for "SSO compatibility" for Gitea. I will start by drafting a list here of related issues and then linking them to existing issues or creating new issues if they don't exist.

Originally created by @kdumontnu on GitHub (Mar 29, 2023). ### Feature Description External auth was initially implemented in gitea with the intention of providing an alternate, parallel method for user login to cloud services (eg. GitHub, OpenID, etc.), and has subsequently been extended to include enterprise services, like Azure AD, Okta, etc. There are a number of issues in the current implementation that don't work when configuring gitea for integration with a single sign-on tool for provisioning users with access control. These range from quality of life to potential security issues if not properly mitigated. Some of these already have associated issues/PRs, but some do not. The goal here should be to enable Gitea accounts to be fully managed from an external auth provider, which is a requirement for most enterprise applications. This issue serves as a tracking thread for "SSO compatibility" for Gitea. I will start by drafting a list here of related issues and then linking them to existing issues or creating new issues if they don't exist. - [ ] Option to hide login form - https://github.com/go-gitea/gitea/issues/16674 - https://github.com/go-gitea/gitea/issues/13606 - [ ] Check external auth for all user interaction - https://github.com/go-gitea/gitea/pull/31572 - Currently, users can generate an auth token for their account (in fact they will need to if they have an account provisioned from an SSO tool). Their token is not validated for access against their SSO provider, so even if access is revoked from SSO, the user can continue to operate using their access tokens. - [ ] SCIM or other "push" based account management - Currently, if an account is removed from OIDC/LDAP it will remain in gitea - Any other changes in user account from external auth tool should be mirrored in gitea, not just on account creation - [x] https://github.com/go-gitea/gitea/issues/23392 - [ ] Remove ability to add/reset password, add/change email, (or any other options that should be overwritten with SSO) - I think this is partially addressed with #20549, but I'll need to look closer - https://github.com/go-gitea/gitea/issues/16852 - [ ] [Map user to admin role with OIDC](https://github.com/go-gitea/gitea/issues/10016)
GiteaMirror added the type/proposaltype/feature labels 2025-11-02 09:11:02 -06:00
Author
Owner

@lunny commented on GitHub (Mar 30, 2023):

There are also #7056, #21672

@lunny commented on GitHub (Mar 30, 2023): There are also #7056, #21672
Author
Owner

@garymoon commented on GitHub (Apr 5, 2023):

Point number 2 (Check external auth for all user interaction) also applies to SSH keys in addition to API keys.

Addressing this point can involve checking the expiry property on the current access token, attempting a refresh if it's expired, and denying access if the access token's expired and a refresh fails. Access key validity periods vary, but as an example Google's live for an hour, so the refresh round-trip should be prohibitively expensive UX-wise.

@garymoon commented on GitHub (Apr 5, 2023): Point number 2 (Check external auth for all user interaction) also applies to SSH keys in addition to API keys. Addressing this point can involve checking the expiry property on the current access token, attempting a refresh if it's expired, and denying access if the access token's expired and a refresh fails. Access key validity periods vary, but as an example Google's live for an hour, so the refresh round-trip should be prohibitively expensive UX-wise.
Author
Owner

@Adphi commented on GitHub (Nov 21, 2023):

This issue is also related #14270.

@Adphi commented on GitHub (Nov 21, 2023): This issue is also related #14270.
Author
Owner

@kdumontnu commented on GitHub (Jul 9, 2024):

I believe this PR https://github.com/go-gitea/gitea/pull/31572 is the last feature needed to effectively close this issue. There are some other issues I linked to in here, but the are more tangential + additional capability.

We should now have everything we need to set up Gitea w/ SSO identity provider.

@kdumontnu commented on GitHub (Jul 9, 2024): I believe this PR https://github.com/go-gitea/gitea/pull/31572 is the last feature needed to effectively close this issue. There are some other issues I linked to in here, but the are more tangential + additional capability. We should now have everything we need to set up Gitea w/ SSO identity provider.
Author
Owner

@Rathlord commented on GitHub (Mar 31, 2025):

@kdumontnu is there any documentation on the external auth feature? I'd like my org to go to authenticating with Entra ID, and this thread suggests that's possible, but there doesn't seem to be anything on the Authentication docs page to suggest that's possible. Am I missing something?

@Rathlord commented on GitHub (Mar 31, 2025): @kdumontnu is there any documentation on the external auth feature? I'd like my org to go to authenticating with Entra ID, and this thread suggests that's possible, but there doesn't seem to be anything on the [Authentication docs page](https://docs.gitea.com/usage/authentication) to suggest that's possible. Am I missing something?
Author
Owner

@TheFox0x7 commented on GitHub (Mar 31, 2025):

I guess docs lack OAuth2 auth source. You can configure it in /-/admin/auths/ page in your instance.

@TheFox0x7 commented on GitHub (Mar 31, 2025): I guess docs lack OAuth2 auth source. You can configure it in `/-/admin/auths/` page in your instance.
Author
Owner

@Mase3206 commented on GitHub (Aug 1, 2025):

@kdumontnu is there any documentation on the external auth feature? I'd like my org to go to authenticating with Entra ID, and this thread suggests that's possible, but there doesn't seem to be anything on the Authentication docs page to suggest that's possible. Am I missing something?

It is definitely possible with Entra and OIDC. I use Authentik in my environment, but OIDC is pretty much universal, with a few quirks of your IdP. Authentik has a really good guide on how to set up OIDC authentication with Gitea: https://integrations.goauthentik.io/development/gitea/

You can also set it up in /-/admin/auths/, as @TheFox0x7 noted. It looks like it has a native profile for Entra, though still under the older "Azure AD" name.


  • SCIM or other "push" based account management
    • Currently, if an account is removed from OIDC/LDAP it will remain in gitea
    • Any other changes in user account from external auth tool should be mirrored in gitea, not just on account creation

I would really like to see SCIM (or even LDAP-based user syncing) implemented. To be honest, in my little homelab, it wouldn't see much use, but it would be very useful in a much larger org with lots of developers, as it could automatically sync user creations/deletions and group membership, which can then be tied to organization membership within Gitea.

@Mase3206 commented on GitHub (Aug 1, 2025): > [@kdumontnu](https://github.com/kdumontnu) is there any documentation on the external auth feature? I'd like my org to go to authenticating with Entra ID, and this thread suggests that's possible, but there doesn't seem to be anything on the [Authentication docs page](https://docs.gitea.com/usage/authentication) to suggest that's possible. Am I missing something? It is definitely possible with Entra and OIDC. I use Authentik in my environment, but OIDC is pretty much universal, with a few quirks of your IdP. Authentik has a really good guide on how to set up OIDC authentication with Gitea: [https://integrations.goauthentik.io/development/gitea/](https://integrations.goauthentik.io/development/gitea/) You can also set it up in `/-/admin/auths/`, as @TheFox0x7 noted. It looks like it has a native profile for Entra, though still under the older "Azure AD" name. <br /> > - [ ] SCIM or other "push" based account management > - Currently, if an account is removed from OIDC/LDAP it will remain in gitea > - Any other changes in user account from external auth tool should be mirrored in gitea, not just on account creation I would really like to see SCIM (or even LDAP-based user syncing) implemented. To be honest, in my little homelab, it wouldn't see much use, but it would be very useful in a much larger org with lots of developers, as it could automatically sync user creations/deletions and group membership, which can then be tied to organization membership within Gitea.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#10551