现已正式发布：使用代表用户授权构建权限感知的 Databricks 应用
内容提要
Databricks Apps 正式推出代表用户（OBO）授权，应用可以登录用户身份调用 API，由 Unity Catalog 自动执行该用户的数据权限，无需在代码中重建治理规则。应用可同时使用服务主体处理自有操作，并按需申请最小 API 范围（如只读查询）。管理员可限制范围，缺失用户令牌时应拒绝而非降级。
延伸解读
OBO 授权如何与 Unity Catalog 协同工作
当应用以 OBO 方式调用 Databricks API 时，它使用登录用户的身份，Unity Catalog 会自动执行该用户已有的数据权限，包括行过滤和列掩码。这意味着应用无需在代码中重建治理规则，管理员更新策略后，后续请求会立即反映变化。例如，销售洞察助手只能返回销售人员有权访问的账户和字段，而区域经理与全国负责人看到的数据范围自然不同。
API 范围是能力上限，而非数据访问授权
应用可以按需申请最小 API 范围，如 sql:restricted-query 仅允许执行只读 SQL 查询，不能进行其他 SQL 操作。但范围只是能力上限，用户仍须拥有目标 SQL 仓库和 Unity Catalog 数据的相应权限。因此，即使应用拥有某个范围，若用户无权访问数据，查询依然会失败。这种设计避免了应用以用户身份获得过宽的操作能力。
管理员如何控制 OBO 范围与故障处理
工作区管理员可以在设置中配置允许的 API 范围白名单，默认支持所有 API，也可缩小到选定范围或设为 None 以禁用用户授权。账户管理员可以添加白名单之外的范围。若管理员移除某个已允许的范围，已运行的应用可继续运行，但无法启动、部署或更新，直到移除该范围。此外，当请求需要用户授权但缺少转发令牌时，应用应拒绝请求而非降级到服务主体，避免返回看似有效但权限不同的结果。
混合使用应用授权与用户授权的实践建议
大多数生产应用需要同时使用两种授权模型：应用授权使用服务主体处理应用自有操作（如读取共享配置、写入指标），用户授权使用登录用户身份处理受治理数据的操作。建议在代码中明确区分身份边界，例如为不同路径使用独立的客户端、依赖和测试，防止应用凭证被误用于用户路径，或用户令牌被保留用于后台任务。对于自定义代理，应在请求时初始化用户作用域客户端，因为转发令牌仅在活跃用户请求期间可用。
Q&A
Databricks Apps 的 OBO 授权是什么？
OBO（代表用户）授权是 Databricks Apps 正式推出的一种授权方式，应用可以登录用户身份调用 API，由 Unity Catalog 自动执行该用户的数据权限，无需在代码中重建治理规则。
OBO 授权如何与 Unity Catalog 配合实现权限感知？
当应用使用 OBO 调用支持的 Databricks API 时，会以登录用户身份执行，Unity Catalog 会强制执行该用户已有的数据权限，包括行过滤和列掩码，同时 API 范围限制应用可以代表用户执行的操作。
应用授权和用户授权有什么区别？
应用授权使用应用专用的服务主体，适用于应用自有操作或对所有用户返回相同结果的体验；用户授权使用登录用户的身份，适用于应由该用户权限管理的操作。大多数生产应用可以同时使用两种模型，为每个请求路径选择合适的身份。
如何为只读分析助手配置最小 API 范围？
只读分析助手应请求 sql:restricted-query 范围，而不是更广泛的 sql 范围。sql:restricted-query 允许应用执行只读 SQL 查询，不允许其他 SQL 操作。如果应用还调用 Genie 或 Unity Gateway，则只请求相应的范围，如 genie 或 ai-gateway。不要请求 files、model-serving 或 vector-search，除非应用实际使用这些功能。
管理员如何限制应用可以请求的 API 范围？
工作区管理员可以在 Settings > Development > Apps 下配置允许列表，默认允许所有支持的 API，可以缩小到选定的 API 范围，或设置为 None 以禁用用户授权。账户管理员可以添加不在工作区允许列表中的范围。如果管理员后来移除了允许的范围，已使用该范围运行的应用可以继续运行，但在移除不允许的范围之前无法启动、部署或更新。
如果请求需要用户授权但缺少转发的令牌，应用应该如何处理？
如果请求需要用户授权但转发的令牌缺失，应用应该失败关闭（fail closed），而不是静默切换到应用的服务主体。否则，应用可能返回看似有效但使用不同权限生成的响应。
