Microsoft OAuth on behalf of流程下Vue+.NET应用调用Graph API的令牌存储方案

核心结论 #

你完全可以不采用浏览器端Cookie存储令牌的方案，所有和Microsoft Graph调用相关的令牌集中在后端侧托管，本身就是微软官方针对后端API调用场景推荐的合规架构，不存在强制要求必须把令牌下发到浏览器端的规则。
你在文档中看到的“可将令牌以Cookie形式存储在浏览器端”的描述，是针对纯前端应用直接调用Microsoft Graph的轻量场景设计的参考方案，并非所有架构下的强制要求，对于你这种“前端触发请求、后端代调Graph”的架构，全后端托管令牌反而比前端存储的安全性更高。

关于refresh token存入自有数据库的规则 #

你可以将refresh token存入你现有的用户信息数据库，但必须满足以下硬性合规要求：

• 绝对不可以明文存储refresh token：refresh token的权限范围远高于短期有效的访问令牌，一旦泄露攻击者可以长期冒用用户身份操作其日历、邮件等资源，存储时必须使用强度符合安全要求的加密机制（比如.NET生态内置的DataProtection组件）做静态加密，且加密密钥必须和数据库本身做物理隔离，不能和业务表存在同一存储环境中。
• 存储时必须做强关联绑定：每条refresh token的存储记录，要和用户的本地系统唯一标识、对应的Microsoft租户ID、用户的Microsoft账号对象ID做一一绑定，不能只存储裸令牌字符串，否则后续遇到令牌轮换时会出现匹配失效的问题。
• 必须做好令牌的同步更新：Microsoft的refresh token自带自动轮换机制，每次你用refresh token换取新的访问令牌时，微软的响应包会同时返回新的refresh token，这时候必须立刻把数据库里存储的旧令牌替换为新的令牌，否则后续调用会因为令牌失效被拒绝，严重时会触发微软的身份保护机制临时锁定用户的授权。

不推荐的存储操作 #

• 不要把微软生态的相关令牌下发到浏览器端：不管是存在localStorage还是Cookie里，浏览器侧的存储环境都更容易被XSS、CSRF攻击窃取。你完全可以把整个OAuth授权流程做后端中转：Vue前端触发授权时直接跳转到微软的授权页面，授权完成后微软将授权码直接回调到你的.NET后端，后端在服务端完成授权码换令牌的全流程，将令牌存到自己的数据库后，给前端签发仅属于你自己系统的会话凭证即可。前端后续所有操作请求，只需要携带这个自有会话凭证和后端通信，全程微软的所有令牌都不需要暴露到前端环境。
• 没必要把微软颁发的短期访问令牌落库存储：访问令牌的有效期通常只有1小时，落库存储不仅没有实际价值，还会增加泄露风险。需要调用Graph API时，后端直接用数据库里存的加密refresh token现换当期的访问令牌，在内存中完成Graph调用即可。

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