[Thread] SSO Auth Tracking

[kdumontnu]

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
  • OIDC First Logon - Force username / email address #16674
  • Allow to disable local login #13606
• Check external auth for all user interaction - allow synchronizing user status from OAuth2 login providers #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
• OAuth registration flow doesn't respect manual confirmation requirement #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 Allow disable part user settings #20549, but I'll need to look closer
  • Gitea does not implement proper OIDC #16852
• Map user to admin role with OIDC

[lunny]

There are also #7056, #21672

[garymoon]

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.

[Adphi]

This issue is also related #14270.

[kdumontnu]

I believe this PR #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.

[Rathlord]

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

[TheFox0x7]

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