Configurable first-party OAuth clients and trusted auto-consent for self-hosted deployments

[XiaoTongYuCode]

Hi Teable team — thank you for maintaining Teable and for making the OAuth server implementation available in the community repository.

I have been looking at how a self-hosted deployment could connect a first-party web, desktop, or companion application through Authorization Code + PKCE. I may have missed an existing extension point, so I would appreciate your guidance on whether the following capability would fit the project.

Background

This use case is separate from using Google OAuth or OIDC to sign users into Teable. Here, Teable acts as the OAuth authorization server and issues a user token to another application in the same product or deployment.

The existing OAuthAppInitService already seems like a strong foundation. It runs during OnModuleInit, uses a distributed lock, and idempotently initializes the built-in Teable CLI OAuth application.

For an additional deployment-owned client, operators currently appear to need manual OAuth application registration, an external bootstrap step, or a custom patch. In addition, authorizeImmediate() only skips the consent page when an OAuthAppAuthorized record already exists, so a new user still sees the first consent screen even for a first-party application.

One possible direction

Optional first-party OAuth application configuration

Would it be useful to support an optional server-side configuration for additional first-party OAuth applications? For example:

[
  {
    "clientId": "cltExampleFirstPartyWeb",
    "name": "Example First-Party Web",
    "homepage": "https://example.com",
    "redirectUris": ["https://app.example.com/auth/callback"],
    "scopes": ["space|read", "base|read_all", "user|email_read"],
    "trusted": true
  }
]

This is only an example configuration shape. trusted could default to false, preserving the normal consent flow unless a deployment explicitly opts in. Keeping registration and trust in one descriptor may help avoid configuration drift, although a separate trusted-client allowlist could also work if it is validated against the configured applications.

Reuse the existing startup initializer

OAuthAppInitService could potentially reconcile both the built-in CLI application and any configured applications:

[cliOAuthApp, ...configuredFirstPartyOAuthApps]

This would keep registration in the official startup lifecycle and allow getOAuthApp() to remain a read-only lookup.

For multi-instance deployments, it may also be helpful for an instance that does not acquire the initialization lock to verify that the configured clients are present before it begins serving authorization requests.

Optional trusted-client consent handling

After the normal client, scope, redirect URI, and PKCE checks have succeeded, the backend could derive trust from an exact server-configured client ID match. The existing IAuthorizeClient type already includes an optional isTrusted field, which may be a suitable place to carry this server-derived decision internally.

A trusted client could then follow the existing immediate authorization path:

if (client.isTrusted) {
  await this.touchAuthorize(client.clientId, user.id);
  return done(null, true, undefined, undefined);
}

All other OAuth clients would continue using the current consent behavior.

Possible safety and compatibility considerations

• With no additional configuration, existing behavior would remain unchanged.
• The built-in CLI client could keep its current consent behavior unless the Teable team prefers otherwise.
• Trust would come only from server configuration, rather than browser parameters or a client-editable database field.
• Matching could remain exact and case-sensitive, without prefixes or wildcards.
• Redirect URI, requested scope, and PKCE validation would still run before any automatic confirmation.
• It may be useful to treat configured applications as system-managed, or to compare their stored redirect URIs and scopes with the server configuration before authorization.
• Invalid or conflicting configuration could be rejected during startup with a clear error.
• If automatic confirmation writes a normal OAuthAppAuthorized record, removing a client from the trusted configuration may not immediately restore the consent page. It would be helpful to clarify the preferred revoke or expiration behavior.

It looks like this may be possible without adding a mutable trusted column to the OAuth application table, because trust can remain a deployment policy. However, I would be very interested in the maintainers perspective on that tradeoff.

Questions

1. Would configurable first-party OAuth applications be useful for supported self-hosted integrations?
2. Would a single application descriptor with an optional trusted flag fit the current configuration style, or would separate configuration be preferable?
3. Should server-configured OAuth applications remain editable in the normal OAuth application management API?
4. For an automatically confirmed client, what authorization-record and revoke semantics would be most consistent with Teable?

If this direction seems appropriate, I would be happy to help prepare a small, generic pull request with configuration validation and focused tests. Thank you for considering it.