MySQL REST Service 认证鉴权体系与 MySQL 26.10.0 内置化演进

MySQL REST Service 认证鉴权体系与 MySQL 26.10.0 内置化演进

摘要

MySQL REST Service（MRS）的安全模型围绕"认证多源、鉴权分层、数据细粒度"三条主线构建。认证层支持 OAuth2、MySQL 原生认证与 MRS 内置认证三种 vendor 并存；鉴权层通过四级管理角色与两类运行时 Provider 角色实现职责分离；数据层则提供行级安全与字段级可见性控制。2026 年 9 月发布的 MySQL 26.10.0 创新版本将 MRS 从 MySQL Router 侧迁移为 Server 内置组件，使数据库进程自身即可提供 HTTPS REST 端点，同时带来了 WebAuthn 社区版支持与 JSON Duality Views 的细粒度控制等配套增强。本文系统梳理 MRS 的认证鉴权架构，并结合 26.10.0 的部署形态变化给出实践参考。

一、认证层：多 Vendor 并存的开放身份体系

MRS 的认证设计并非绑定单一机制，而是允许多种认证方式在同一部署中共存。根据官方文档，MRS 支持三类认证 vendor：MRS REST 服务特定认证、MySQL 内部认证，以及 OAuth2 认证（如 Facebook、Google 登录）。这一设计的出发点在于：不同类型的应用对身份来源的诉求差异显著，强制统一认证方式会牺牲灵活性。

OAuth2 认证 面向公网 Web 与移动应用。MRS 允许 REST 服务对接外部 OAuth2 身份提供方，终端用户以社交或企业账号登录。关键架构特征是：通过 OAuth2 vendor 认证的用户，其数据访问权限并不来自用户自身的 MySQL 权限，而是统一经由 mysql_rest_service_data_provider 角色执行。这意味着数据库层面只需信任一个服务角色，终端用户的细粒度控制完全交由 MRS 层的鉴权机制处理，OAuth2 用户与数据库原生账号实现了逻辑解耦。

MySQL Internal 认证走另一条路径。使用该 vendor 的 REST 用户直接以自身 MySQL 权限访问数据，不使用 data provider 角色。这适合已建立完整 MySQL 账号与权限体系的场景，可复用既有数据库安全投资。文档亦指出，此方式适用于"未公开暴露的应用程序"。

MRS 内置认证 提供 REST 服务自有的用户管理能力。在 TypeScript 客户端中，调用 authenticate() 方法即可触发登录交互，但该函数仅适用于内置 MRS vendor，使用前需确认 REST Authentication App 已按此方式配置。

三种 vendor 的并存，本质是在"身份从哪来"的层面提供选择权，而真正的"能做什么"则下沉至鉴权层。

二、鉴权层：管理角色与运行时角色的双轨 RBAC

MRS 的 RBAC 体系在两个维度上展开：管理侧的四级角色分层，与运行时的 Provider 角色隔离。

管理侧四级角色

MRS 定义了一套从高到低的管理角色，控制"谁可以配置和开发 REST 服务"：

角色	能力范围
mysql_rest_service_admin	全部功能的完整访问权
mysql_rest_service_schema_admin	可在现有 REST 服务下添加新的 REST schema 与端点
mysql_rest_service_dev	可为现有 REST schema 定义新的 REST 端点
mysql_rest_service_user	任何访问 REST 端点的 MySQL 用户均需被授予此角色

这一分层遵循最小权限原则：开发者持 dev 角色即可定义端点，schema 管理员负责 schema 级变更，全局控制权保留在管理员手中。实践中需注意角色激活问题：MySQL 角色须通过 SET ROLE 激活，而在 VS Code 扩展场景下还需通过 SET DEFAULT ROLE 纳入默认角色集，否则连接建立时不会自动生效。

运行时 Provider 角色

MRS 组件本身（无论运行于 Router 还是 Server 组件中）使用两个专用角色操作数据库：

• mysql_rest_service_meta_provider：只读访问元数据 schema，识别需提供的 REST 服务；
• mysql_rest_service_data_provider：读写应用数据，供 MRS 认证及 OAuth2 认证的 REST 用户使用。

26.10.0 的组件安装文档进一步明确了这两个角色的执行上下文：组件创建或验证两个锁定内部账号 mysql_mrs_metadata@localhost 与 mysql_mrs_data@localhost，分别以对应 Provider 角色作为默认角色。这些账号无密码、不可用于客户端登录，仅作为内部授权身份存在。元数据 SQL 以 mysql_mrs_metadata 执行，应用数据 SQL 通常以 mysql_mrs_data 执行，配置为 MySQL 用户透传的请求则以认证后的 MySQL 账号安全上下文运行。

一个易被忽视的授权盲区是：REST view 所需权限自动授予，REST procedure/function 的 EXECUTE 权限亦自动授予，但存储过程内部若调用其他过程或对象，嵌套对象的权限不会自动传递。必须手动为 mysql_rest_service_data_provider 角色执行 GRANT，否则端点在运行时会报错。

三、数据权限与字段权限：行级与列级的可见性控制

MRS 在数据层面的授权模型提供了多个层级：公开访问（无需授权）、完整访问（认证后全量数据）、有限访问（认证后部分数据）。内置授权模型涵盖基于用户所有权、基于角色、基于用户层级、基于群组以及基于群组层级等多种方式。若项目需求恰与某一内置模型匹配，则无需自行实现自定义授权逻辑。

行级安全通过 REST 对象创建时的行所有权选项启用。交互式向导中的 "Should row ownership be required when querying the object?" 即为此控制入口。启用后，不同用户查询同一 REST 视图时只能看到属于自身的数据行，无需为每个用户创建独立的数据库对象。

字段级权限 则通过 REST data mapping view 的字段映射实现。定义视图时仅暴露选定的列（如 cityId: city_id、city: city 的显式映射），未映射的列自然不会出现在返回的 JSON 文档中。此外，@nocheck 属性可将特定字段排除在 ETag 校验之外，在字段权限与并发控制的交叉点上提供精细调节。

MRS 的无锁乐观并发控制 与数据权限协同工作：每个返回对象携带 _metadata.etag 校验和，PUT 更新时若 ETag 不匹配则返回 HTTP 412，客户端需重新获取后重试。这一机制在多用户并发场景下保证一致性，而无需引入数据库锁。26.10.0 为 JSON Relational Duality Views 新增的 CHECK/NO CHECK 注解，使开发者可以决定哪些字段参与 ETag 计算，从而将频繁变动但不影响冲突判断的字段排除在并发校验之外。

四、MySQL 26.10.0：MRS 的 Server 内置化与配套演进

4.1 从 Router 侧到 Server 内置

26.10.0 最具实质性的变化，是 MRS 可以 Server Component 形式直接运行于 MySQL Server 内部，不再强制依赖独立的 MySQL Router 进程作为 HTTPS 前端。安装方式为：

INSTALL COMPONENT 'file://component_mysql_rest_service';

组件默认监听 HTTPS 端口 33443，可通过系统变量 mysql_rest_service.http_port 调整。安装是异步启动的，INSTALL COMPONENT 成功返回仅表示注册与启动请求被接受，并不代表 HTTPS 监听已就绪。必须通过状态变量确认：

SHOW GLOBAL STATUS LIKE 'mysql_rest_service.state';

只有当状态变为 READY 时，元数据、内部账号、安全上下文、TLS 上下文与 HTTPS 监听才全部初始化完成。启动失败会转入 ERROR 状态，详细原因写入 MySQL Server 错误日志。

生命周期由三个 SQL 函数控制：mysql_rest_service_start()、mysql_rest_service_stop()、mysql_rest_service_restart()，调用者需持有 MYSQL_REST_SERVICE_ADMIN 动态权限。

4.2 部署注意事项

安装 MRS 组件前有一个容易被忽略的前置条件：若 validate_password 组件已启用，则无法安装 MRS 组件，因为该组件禁止创建无密码内部账号。通过 YUM、SLES 或 Oracle RPM 安装的 MySQL 26.10 默认启用 validate_password，需先行处理。

配置顺序上，应先执行 CONFIGURE REST METADATA; 配置元数据 schema，再安装组件。元数据配置会创建内部账号定义所需的 Provider 角色。

4.3 配套能力增强

WebAuthn 进入社区版 。authentication_webauthn 服务器插件在 26.10 创新版中对社区版开放，支持 FIDO 设备的多因素认证与无密码登录。需注意，这是数据库账号登录层的增强，与 MRS 的 REST 终端用户认证属于不同层面，不应混淆。

Health Monitor 进入社区版。此前仅 HeatWave 可用的资源监控组件下放至社区版，可观测 CPU、内存、文件系统与磁盘预测数据。Linux 支持全部指标，macOS 提供基础内存、文件系统与 CPU 指标，Windows 此版本不支持。

分区裁剪可见性提升 。EXPLAIN FORMAT=TREE 与 JSON v2 格式现在会显示查询计划中选定的分区，便于开发者诊断分区裁剪行为。

4.4 版本定位

26.10.0 是创新版本（Innovation Release），采用年份后两位与月份组合的日历版本命名，并非 LTS。其定位是先行引入新特性供评估，生产环境仍应以 8.4 LTS 或 9.7 LTS 为基准。MRS Server 内置组件、WebAuthn 社区版支持等新能力，适合在预发环境或新项目中验证，不建议直接替换现有 LTS 部署。

五、复杂场景的架构扩展

对于超出 MRS 内置能力的鉴权需求，合理的架构策略是在 MRS 之前叠加网关层。这一分层的逻辑在于职责分离：

• 网关层承担 IP 白名单、速率限制、WAF、JWT 预校验、跨服务统一身份等边界安全职责；
• MRS 层聚焦于基于角色的细粒度鉴权以及行级/字段级数据权限；
• 网关完成粗粒度过滤后透传请求，MRS 执行数据与应用层的安全策略。

这种模式避免了在单一组件中堆砌过多策略逻辑，也使安全边界更加清晰可审计。

六、实践建议

第一，按消费方应用划分 REST 服务。每个应用使用独立的 REST 服务，认证选项与授权策略可按应用隔离，避免单一服务承载异构客户端带来的策略耦合。

第二，认证 vendor 按场景选择。已有 MySQL 账号体系且服务不对公网暴露时，MySQL Internal vendor 可复用既有权限；面向公网移动应用或 PWA 时，OAuth2 更为合适；快速原型阶段，MRS 内置认证最为便捷。

第三，核查 Provider 角色的授权完整性 。存储过程嵌套调用、跨对象访问等场景，务必确认 mysql_rest_service_data_provider 角色已获得所有必要权限，不依赖自动授予。

第四，26.10.0 部署前检查 validate_password 状态。若该组件已启用，需先按官方 workaround 创建锁定内部账号，否则组件安装将失败。

第五，善用 ETag 控制与 Duality Views 注解配合 。在启用行级安全的多用户场景下，乐观并发控制是保证一致性的有效手段；26.10.0 的 NO CHECK 注解进一步允许将不参与冲突判断的字段排除在 ETag 之外，减少无意义的 412 响应。

结语

MySQL REST Service 的安全架构可以概括为：认证层开放多源，鉴权层分层隔离，数据层精细到行与列，边界层可外延至网关。OAuth2 解决了公网身份接入问题，四级管理角色与双 Provider 角色实现了管理与运行时的职责分离，行级安全与字段映射提供了数据可见性的细粒度控制。MySQL 26.10.0 将 MRS 内置为 Server 组件，消除了对独立 Router 进程的强制依赖，使这一安全体系得以在数据库进程内闭环运行。理解分层逻辑比记忆具体语法更为重要------它决定了在具体项目中，每一类安全策略应当放置在哪一层来实现。

文章来自于：https://dev.mysql.com/doc/dev/mysql-rest-service/latest/#overview