feat: add Doris-backed OAuth authentication#90
Open
catpineapple wants to merge 2 commits into
Open
Conversation
Add Doris OAuth mode backed by Doris RBAC and make it mutually exclusive with the existing OAuth provider. Bind MCP requests to authenticated Doris users with per-user connection pools and operation policy enforcement. Add Doris OAuth token handling, redirect validation, rate limiting, MCP auth middleware, and resource metadata cache safeguards. Document token TTL configuration, static client behavior, and current token/pool lifecycle semantics. Add tests for OAuth routes and store behavior, auth context propagation, operation policy checks, resource cache safety, user pool management, and guarded tool execution.
Merge upstream master into the Doris OAuth branch. Resolve the HTTP transport conflict by preserving MCP authentication middleware while applying CORS handling to MCP preflight, auth errors, authorization errors, and normal session responses. Add shared MCP CORS helpers for single-worker and multi-worker HTTP routes. Replace the Doris OAuth smoke test runtime-file dependency with an inline environment fixture.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Doris OAuth Implementation Notes and Limitations
This PR adds a Doris-backed OAuth mode. In this mode, the MCP server
acts as the OAuth provider. Users sign in with their Doris username
and password; the server validates those credentials against Doris and
creates a dedicated per-user Doris connection pool. Subsequent MCP
requests are bound to that user pool, and data/metadata authorization
is ultimately enforced by Doris RBAC.
Relationship With Existing OAuth
doris-oauthis mutually exclusive with the existing external OAuth/OIDC mode. External OAuth/OIDC delegates identity to a third-party
identity provider, while Doris OAuth uses Doris itself as the
authentication and authorization backend. They cannot be enabled at
the same time to avoid mismatches between MCP identity and Doris
execution identity.
Token Lifetime
Doris OAuth access and refresh token lifetimes are configurable:
DORIS_OAUTH_ACCESS_TOKEN_EXPIRE_SECONDS, default900DORIS_OAUTH_REFRESH_TOKEN_EXPIRE_SECONDS, default86400When an access token expires, the client must refresh it with a valid
refresh token. When the refresh token expires or is revoked, the user
must sign in again.
Connection Pool Lifecycle
A per-user Doris connection pool is created after successful login.
Doris OAuth requests must execute through that bound user pool. If a
token is valid but the corresponding user pool is missing, the request
fails closed and never falls back to the global Doris service account.
The current implementation closes Doris OAuth user pools during server
shutdown and covers revoke-related paths. However, automatic pool
disposal when access/refresh tokens naturally expire is not yet a
complete capability. The following configuration is reserved:
DORIS_OAUTH_GC_INTERVAL_SECONDSDORIS_OAUTH_IDLE_TIMEOUT_SECONDSThese options should not be interpreted as full token-expiry-driven
pool cleanup yet.
DCR Limitations
Basic Dynamic Client Registration support is included, with the
following configuration:
DORIS_OAUTH_DYNAMIC_CLIENT_REGISTRATION_MODEDORIS_OAUTH_DCR_MAX_CLIENTSDORIS_OAUTH_DCR_CLIENT_TTL_SECONDSDORIS_OAUTH_DCR_RATE_LIMIT_PER_IPDCR clients, authorization codes, access tokens, and refresh tokens
are currently memory-only and process-local. They are not shared
across workers, processes, or nodes.
Multi-Worker and Multi-Node Limitations
Doris OAuth is not currently a stateless horizontal-scaling
implementation. Token state, DCR client state, authorization code
state, and per-user Doris connection pools are all process-local.
For this reason, the recommended deployment shape for Doris OAuth is:
WORKERS=1 True multi-worker or multi-node deployment requires a future shared token store, shared DCR client store, shared authorization code store, and either per-user pool reconstruction or sticky-session routing. ### Resource Cache and Metadata Isolation Doris OAuth must avoid cross-tenant metadata leakage. For example, database/table metadata visible to user A must not be cached and later exposed to user B. This PR adds safeguards around resource metadata caching so Doris OAuth resource and tool access remains scoped to the current Doris user, with final visibility controlled by Doris RBAC.