catpineapple opened a new pull request, #90:
URL: https://github.com/apache/doris-mcp-server/pull/90
## 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-oauth` is 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`, default `900`
- `DORIS_OAUTH_REFRESH_TOKEN_EXPIRE_SECONDS`, default `86400`
When 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_SECONDS`
- `DORIS_OAUTH_IDLE_TIMEOUT_SECONDS`
These 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_MODE`
- `DORIS_OAUTH_DCR_MAX_CLIENTS`
- `DORIS_OAUTH_DCR_CLIENT_TTL_SECONDS`
- `DORIS_OAUTH_DCR_RATE_LIMIT_PER_IP`
DCR 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:
```bash
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
