能否在Office-JS加载项SSO接入Microsoft Graph时完全不使用服务器？

• 依托Office内置能力实现的无感SSO流程，强制要求服务器侧参与，不存在可以纯客户端安全实现Graph调用的方案。
  其中的逻辑很直接：Office JS提供的getAccessToken方法拿到的bootstrap令牌，受众是你在AAD注册的应用本身，不是Microsoft Graph服务，没法直接拿这个令牌去调用Graph接口。要拿到可用的Graph访问令牌，必须走OBO（代表用户）的令牌交换流程，这个流程在AAD侧要求应用提供客户端认证凭证（也就是client secret或者证书）来证明请求的合法性。这类凭证如果放到纯客户端代码里，等于直接公开给所有访问加载项的终端用户和恶意第三方，没有任何安全防护可言。
• 确实存在完全不带服务器的客户端直连Graph的方案，但完全达不到SSO的体验要求：这种方案需要把AAD应用配置成公开客户端类型，加载项自己弹出Azure AD的交互式登录窗口让用户手动输入账号信息登录，拿不到Office原生的无感登录效果，每次打开加载项都要重复登录，企业客户基本不会接受这种体验，也不符合多数企业的身份合规要求。

• 这种做法属于明确的安全缺陷，没有任何现有配置可以完全抵消风险。
  具体原因：
  • 加载项的manifest文件本身是全量暴露给终端用户的：不管是从Office客户端的本地安装目录、还是管理员分发安装的XML配置路径，任何安装了该加载项的用户都可以完整读取manifest里的所有内容，写在里面的client secret相当于直接公开。
  • 你提到的Application URI配置限制，只能在常规流程下拦截非授权的应用使用，根本挡不住已经拿到secret的恶意方：对方可以完全模仿你合法服务的请求特征、伪造相同的应用标识，直接用窃取到的secret走OBO流程，以你们应用的名义调用Graph接口，窃取客户租户内的邮件、日历、个人文件数据，这类凭证泄露事件会直接触发AAD的风险检测机制，导致你们的应用被全域封禁。
  • 就算是给每个客户单独配专属secret写入对应客户的manifest，后续的密钥轮换成本也完全不可控：只要secret因为任何原因需要更新，你需要逐个修改所有客户的manifest，重新推送全量部署，没有任何自动化运维的空间。

你提到现有加载项服务之前只做静态脚本托管，没有复杂的密钥管理能力，其实不需要搭建完整的密钥管理系统就可以落地SSO流程：

• 可以先把所有应用注册对应的client secret存在现有服务的加密配置文件或者服务环境变量里，完全不暴露给客户端请求路径，只需要加一个轻量的后端中转接口：客户端把getAccessToken拿到的bootstrap令牌传给这个接口，接口根据请求携带的客户租户标识匹配对应的client secret，在服务器侧完成OBO换Graph令牌的流程，再把令牌返回给客户端使用，整个逻辑没有复杂的依赖，静态托管服务加几十行后端代码就可以实现。
• 如果不想为每个客户单独维护一套应用注册和对应的secret，完全可以调整成单一多租户应用适配所有客户的模式：所有客户的SSO流程都共用你们中心服务名下的同一个开启多租户配置的AAD应用，只需要维护一份应用凭证就行。这种模式下，每个客户的租户管理员只需要对这个共用应用完成一次性的管理员同意，就可以正常跑通SSO，不需要给每个客户单独创建应用注册、单独维护密钥，从根本上解决多密钥匹配管理的问题。
• 不管选哪种方案，核心红线是：client secret、证书这类应用级凭证，绝对不能出现在客户端可访问的脚本、manifest这些公开位置，所有涉及凭证的认证流程必须在你自有可控的服务器侧完成。

内容的提问来源于stack exchange，提问作者test35423532523523