Summary
The OAuth token strategy attached oauth_scope and oauth_granted_resources to the request user, but the ACL middleware never consulted either. An OAuth token issued with a restricted scope (e.g. MCP-only) therefore inherited the full permissions of the underlying user across all routes; the granted_resources.base_id restriction was bypassed on org-level endpoints that don't populate req.context.base_id.
Details
In packages/nocodb/src/strategies/oauth-token.strategy.ts, the strategy set is_oauth_token, oauth_client_id, oauth_granted_resources, and oauth_scope on the user object, then mapped through to the user's existing roles / base_roles. The ACL middleware in extract-ids.middleware.ts honoured is_api_token via blockApiTokenAccess but had no equivalent gate for is_oauth_token or scope-string enforcement.
The base/workspace restriction logic short-circuited when req.context.base_id was unset (org-level routes), so an OAuth token scoped to one base could still call org-level endpoints as the underlying user.
The fix adds a path-prefix allowlist (['/mcp', '/api/v3/', '/auth/user/me']) enforced inside the strategy and a blockOAuthTokenAccess ACL flag for endpoints that should never accept OAuth tokens.
Impact
- Scope escalation: tokens issued with a narrow scope received the underlying user's full role.
- Resource boundary bypass: per-base restrictions did not apply to org-level routes.
- Violates least-privilege expectation for third-party OAuth integrations.
Credit
This issue was reported by @ik0z.
References
ik0z Reporter
Summary
The OAuth token strategy attached
oauth_scopeandoauth_granted_resourcesto the request user, but the ACL middleware never consulted either. An OAuth token issued with a restricted scope (e.g. MCP-only) therefore inherited the full permissions of the underlying user across all routes; thegranted_resources.base_idrestriction was bypassed on org-level endpoints that don't populatereq.context.base_id.Details
In
packages/nocodb/src/strategies/oauth-token.strategy.ts, the strategy setis_oauth_token,oauth_client_id,oauth_granted_resources, andoauth_scopeon the user object, then mapped through to the user's existingroles/base_roles. The ACL middleware inextract-ids.middleware.tshonouredis_api_tokenviablockApiTokenAccessbut had no equivalent gate foris_oauth_tokenor scope-string enforcement.The base/workspace restriction logic short-circuited when
req.context.base_idwas unset (org-level routes), so an OAuth token scoped to one base could still call org-level endpoints as the underlying user.The fix adds a path-prefix allowlist (
['/mcp', '/api/v3/', '/auth/user/me']) enforced inside the strategy and ablockOAuthTokenAccessACL flag for endpoints that should never accept OAuth tokens.Impact
Credit
This issue was reported by @ik0z.
References