钉钉、企业微信、飞书的自定义应用权限对比

结论：审批、待办和组织流程集成优先评估钉钉；内部协作同时要连接微信客户生态优先评估企业微信；文档、知识库、日历和多维表协同优先评估飞书。若企业已经大规模使用其中一套平台，迁移成本通常比单个 API 差异更重要；最终必须拿真实业务链路验证 Scope、调用身份、数据范围和资源权限。

企业在钉钉、企业微信和飞书之间做集成选型时，经常只比较“有没有某个接口”。真正影响落地的，是管理员要批什么、员工是否还要单独授权、应用能看到哪些人，以及拿到接口权限后能否访问目标资源。

本文比较的是企业内部使用的自建应用 / 企业内部应用，不包括面向多个企业上架的第三方应用，也不把群 Webhook 机器人当成完整自建应用。内容依据三家官方开放平台资料整理，校对日期为 2026 年 8 月 24 日。

做真实选型时，滚水科技不会要求客户先研究三套权限体系。我们会把目标流程拆成调用动作、身份、Scope、组织范围和资源授权，用客户提供的测试组织与业务账号完成最小权限 PoC，再交付平台建议、权限矩阵、管理员操作清单和上线回收方案。客户只需说明实际协作流程、数据负责人和哪些动作必须人工批准，并由组织管理员完成最终授权。

---

一、先理解四层权限，避免把“已授权”理解错

一次 API 调用能否成功，通常要同时通过以下四层：

1. 接口权限（Scope）： 应用是否申请了读取通讯录、发送消息、读取审批等能力；
2. 身份权限： 当前是以应用身份运行，还是代表已登录用户运行；
3. 数据范围： 应用可以接触全员、指定部门，还是指定成员；
4. 资源权限： 目标文档、知识库、群聊、日历或多维表是否真的向该应用或该用户开放。

可以把最终权限理解为：

实际可访问数据 = 接口权限 ∩ 调用身份可访问范围 ∩ 应用数据范围 ∩ 资源自身权限

因此，“应用对全公司可见”通常只说明谁能在工作台看到或使用它，并不自动等于应用可以读取全公司的聊天、文档和日历。

---

二、三家平台权限模型总览

这张表只能用于理解模型，不能替代具体 API 页面的“权限要求、字段权限、可访问范围和调用身份”说明。

---

三、钉钉：重点看“委托权限”和“应用权限”

钉钉的权限模型适合先按调用身份拆开理解。根据钉钉官方权限概述，权限分为委托权限和应用权限：

• 委托权限： 应用代表已登录用户访问资源。用户需要同意授权，应用不能越过该用户本来拥有的访问权限；
• 应用权限： 后台服务直接以应用身份访问，不要求某个用户正在登录，适合同步、自动化和定时任务。此类权限影响范围更大，只能由组织管理员授予。

通讯录

读取成员、部门与角色数据时，除了申请对应权限点，还应明确应用的数据范围。通讯录写入属于高风险操作，钉钉对部分敏感权限设置了额外的管理员角色要求。例如官方敏感权限说明明确将通讯录管理列为需要特定管理员授权的能力。

实施时不要默认申请通讯录写权限。多数通知、审批同步和数据查询场景，只需要只读的成员标识、姓名、部门等最小字段。

消息与机器人

钉钉的自定义机器人、企业机器人和企业内部应用不是同一个权限模型。群 Webhook 机器人适合向指定群推送，但不能替代需要用户身份、通讯录、审批或待办 API 的内部应用。工作通知、机器人消息、群事件等能力应分别核对发送对象范围、机器人是否在群内以及接口权限。

审批、待办与日程

钉钉在审批、待办和组织流程集成方面接口较完整。后台自动创建待办或同步审批适合使用应用身份；如果操作的是某个员工的个人资源，则应优先检查接口是否要求委托权限或用户授权，而不是用高权限应用身份绕过个人边界。

适合选择钉钉的情况： 企业已经深度使用钉钉审批、待办和组织管理，希望自定义系统继续围绕这些流程运行。

---

四、企业微信：应用可见范围是重要边界，但不是全部边界

企业微信自建应用通常由企业管理员创建，通过企业 ID、应用 AgentId 和 Secret 获取访问令牌，再调用应用具备的接口。它的管理方式直观，但最容易出现两个误解。

误解一：应用对全员可见，就能读取全员全部数据

应用可见范围首先控制哪些成员可以看到和使用应用，也会影响部分通讯录、消息发送和身份识别能力。但聊天内容、客户联系、审批、文档等仍有各自接口和权限要求，不能由“全员可见”一项推导出来。

误解二：应用能发送消息，就能读取员工聊天记录

自建应用可以向可触达成员发送应用消息，也可以接收发给应用的消息或配置相应事件回调。这不等于应用可以任意读取员工之间的单聊和群聊历史。涉及会话内容存档时，要单独评估会话内容存档产品能力、合规告知、员工或外部联系人同意以及企业的管理责任。

通讯录

企业微信的成员与部门接口和应用范围联系紧密。开发前应先确定应用究竟需要：

• 仅识别当前登录成员；
• 读取指定部门及其成员；
• 向指定范围发送通知；
• 维护通讯录，还是只做单向读取。

只做内部工具时，不建议为了省事直接把应用范围设为全公司。可以先给项目组或试点部门开放，验证稳定后再扩大。

客户联系、审批与办公数据

客户联系、审批、日程、会议、文档等能力属于不同产品域。即使应用已创建并取得访问令牌，也要逐项检查企业是否启用了对应能力、应用是否具有接口权限、目标成员是否在允许范围，以及接口是否要求额外授权。

企业微信开发时应以企业微信开发者中心每个接口当前列出的权限与限制为准。

适合选择企业微信的情况： 员工日常沟通和客户运营都在企业微信内，需要把 CRM、工单、客户服务或内部系统入口放进企业微信，并依靠应用消息持续触达员工。

---

五、飞书：Scope 很细，但 Scope 通过不等于资源已经授权

飞书把应用身份和用户身份明确分开：

• tenant_access_token： 应用代表企业或团队执行操作，可读写范围由应用自身权限与数据范围决定；
• user_access_token： 应用代表已授权用户执行操作，遵循该用户本来拥有的资源权限。

飞书官方对其工具权限机制的说明强调，应用身份与用户身份相互独立、权限不互相继承，能力要先获得相应 Scope，并由租户管理员控制应用准入与权限审批。可参考飞书 CLI 能力与安全说明。

通讯录与字段权限

读取用户和部门时，不仅要申请通讯录 Scope，还要配置通讯录权限范围。部分接口另外列出字段权限要求；能获得用户 ID，不代表手机号、邮箱等字段也会自动返回。

文档、知识库与多维表格

这是飞书权限最常见的踩坑点：应用开通了文档或知识库 Scope，调用仍可能返回无权限。原因通常是应用身份并未获得目标文档、文件夹或知识空间的资源权限。

例如，读取指定知识库时，除了只读 Scope，还可能需要把应用机器人加入有权限的群，再让该群成为知识空间成员或管理员。换句话说：Scope 决定“能不能调用这一类 API”，资源授权决定“能不能碰这一份数据”。

日历与个人操作

如果应用要代表员工创建个人日程、访问其个人资源，优先使用用户身份并取得用户授权；后台统一创建应用自己的日历或处理企业级自动化，则可以评估应用身份。两种令牌不能混用，也不能期待应用身份自动继承某位管理员的权限。

发布与审核

新增权限、事件订阅或可用范围后，通常要创建新版本、发布，并由企业管理员审核后才会在正式环境生效。开发环境里可以调用，不代表生产版本已经拥有相同配置。

适合选择飞书的情况： 业务高度依赖云文档、知识库、日历、多维表格和协同自动化，并愿意对 Scope、应用身份和单个资源权限进行细致治理。

---

六、按常见需求怎么选

不存在脱离企业现状的“权限最强平台”。如果员工和业务数据已经沉淀在某个平台，迁移成本、管理员治理习惯和目标资源的实际可访问性，通常比接口数量更重要。

---

七、上线前的最小权限清单

1. 先按业务动作列权限，不按产品模块全选

把需求写成“读取指定部门姓名和 user ID”“向项目成员发送审批结果”，不要写成“开通讯录权限”“开消息权限”。动作越具体，越容易找到最小 Scope。

2. 分开记录四种范围

在权限清单中分别记录：接口 Scope、应用可用范围、通讯录数据范围、资源成员或 ACL。任何一项为空，都可能导致生产环境失败。

3. 读写权限分开申请

首期只做查询和提醒时，不申请删除、转移所有权、通讯录写入或审批代办等高风险权限。确实需要写操作时，再为关键动作增加人工确认、幂等控制和审计日志。

4. 区分应用身份和用户身份

后台定时任务优先使用应用身份；明确代表某位员工的操作优先使用用户身份。日志中记录操作者、授权主体、令牌类型、资源 ID 和结果，避免事后无法解释“是谁改了数据”。

5. 用试点范围验证

先开放给测试部门、测试群、测试日历和测试文档。分别验证普通员工、部门负责人、管理员和离职 / 调岗成员，尤其测试权限收回后令牌与缓存是否仍能访问。

6. 建立权限变更流程

新增权限必须说明业务原因、数据范围、保存期限和负责人；下线功能时同步撤销 Scope、Secret、事件回调、群成员和资源授权，而不只是删除前端入口。

7. 保护应用凭证

App Secret、应用 Secret 和访问令牌只能保存在服务端密钥系统，不应写进前端、小程序包、代码仓库、日志或普通在线表格。配置轮换和泄露后的吊销方案。

---

八、最终结论

• 钉钉： 适合以审批、待办和组织流程为核心的企业集成；设计时重点区分委托权限与应用权限。
• 企业微信： 适合内部协作与微信客户生态连接；重点核对应用可见范围、通讯录范围和各产品域的独立要求。
• 飞书： 适合文档、知识、日历和多维表协同；重点处理 Scope、应用 / 用户身份和资源 ACL 的叠加关系。

真正稳妥的选型方法不是比较谁能申请更多权限，而是拿一条真实业务链路逐步验证：谁发起、以什么身份调用、需要哪个 Scope、能看到哪些人、目标资源是否授权、管理员如何审批、权限如何撤销。

滚水科技会把这条验证链写进方案与验收用例，并默认优先沿用企业已有的主协作平台；只有现有平台在关键资源、身份或审批能力上无法满足目标时，才建议引入第二个平台或单独建设适配层。