Summary

Allow OneDev to act as an OAuth2 authorization server (and optionally an OpenID Connect provider), so third-party applications can authenticate OneDev users and access the OneDev API on their behalf with explicit user consent. This is equivalent to what Gitea, Forgejo, GitHub and GitLab provide.

Current behavior

As far as I can tell:

• OneDev can be an OIDC client. Users can sign in to OneDev through an external IdP via SSO connectors.
• OneDev has no OAuth2 authorization server. There is no way to register an OAuth application, no authorize/token endpoints and no user consent screen.
• API access from external tools relies on personal access tokens. Each user must create a token and paste it into the tool.

Problem

Tools that integrate with a Git platform commonly offer "Sign in with " and then act on the user's behalf. Many libraries and products ship ready-made providers for GitHub and GitLab, and for Gitea and Forgejo through their OAuth2 support. Because OneDev exposes no standard OAuth2 endpoints, these tools cannot integrate with it without manual token handling or an extra identity provider in front.

Use cases:

• Developer portals and internal tools (login plus repository, PR and build data)
• Web apps built with Auth.js/NextAuth, Better Auth, Spring Security and similar frameworks
• IDE and editor extensions that need delegated access without users pasting tokens
• Cloud IDE and workspace tools that clone and push on the user's behalf
• Dashboards and bots showing per-user data
• Mobile or desktop clients that need a standard login flow

Proposed solution

Add an OAuth2 authorization server to OneDev with the following.

1. Application registration

   • Users can register OAuth applications (name, homepage, redirect URIs, confidential vs. public client).
   • Admins can register instance-wide applications and optionally pre-approve trusted ones.
   • Client ID and secret generation, with secret rotation.

2. Authorization Code flow with PKCE (S256)

   • Authorization endpoint with a consent screen listing the requested scopes.
   • Token endpoint supporting authorization_code and refresh_token grants.
   • Support for state and strict redirect URI matching.
   • PKCE required for public clients and recommended for all.

3. Scopes mapped to OneDev permissions

   • For example: read user profile/email, read/write repositories, read/write issues and pull requests, read builds, read packages.
   • An app can never gain more than the authorizing user's own permissions.

4. Token management

   • Short-lived access tokens plus refresh tokens.
   • Users can list and revoke authorized applications.
   • Admins can revoke all tokens for an app.

5. Discovery and OIDC (optional but valuable)

   • Publish authorization-server metadata (/.well-known/oauth-authorization-server, RFC 8414).
   • Optionally issue ID tokens and provide /.well-known/openid-configuration, a JWKS endpoint and a userinfo endpoint, so generic OIDC providers work out of the box.

6. Security

   • Audit log entries for application registration, grants and revocations.
   • Clear consent UI and per-app authorization history.

Prior art

• Gitea acts as an OAuth2 provider (authorize at /login/oauth/authorize, token at /login/oauth/access_token), using Authorization Code with PKCE support.
• Forgejo does the same and also allows instance-wide applications registered by admins.
• GitHub (OAuth Apps and GitHub Apps) and GitLab (Applications, with OIDC support) provide equivalent functionality.

Acceptance criteria

• A third-party app registered in OneDev can complete the Authorization Code + PKCE flow and obtain an access token and refresh token.
• The token can call the OneDev REST API within the granted scopes and the user's own permissions.
• A user can see and revoke authorized apps.
• An admin can manage instance-wide apps.
• A generic OAuth2/OIDC client library can integrate using only the discovery metadata.

Non-goals (initial version)

• Device authorization grant, client credentials and implicit/password grants (can follow later).
• Dynamic client registration.

Alternatives considered

• Putting Keycloak or another IdP in front, with OneDev as an OIDC client. This handles login, but the app still has no delegated access to OneDev data.
• Personal access tokens. These work for scripts but need manual setup and give no consent flow, per-app scoping or per-app revocation.