Azure日历写入权限方案咨询：应用权限vs委派权限选择

一、当前应用权限方案的利弊 #

优点 #

• 彻底摆脱用户Azure令牌的有效期限制，不用处理令牌过期导致的用户重登问题，功能可用性更稳定
• API层无需依赖用户传递Azure令牌，减少了令牌传输环节的泄露风险，逻辑实现更简单
• 适合批量操作、后台自动化这类无需用户实时参与的场景

风险与问题 #

• Calendar.Write应用权限是全局级别的，你的服务主体将拥有租户内所有用户的日历写入权限，权限过大——一旦服务主体密钥泄露，攻击者可随意篡改所有用户的日历，安全隐患极高
• 用应用权限创建的日历事件，创建者会显示为服务主体而非用户本人，不符合用户操作自己日历的预期
• 违反最小权限原则，Azure AD权限治理中不推荐使用超出业务需求的宽泛权限

二、委派权限方案的利弊 #

优点 #

• 权限精准：Calendar.Write委派权限仅允许以当前用户身份访问其自身日历，符合最小权限原则，安全风险可控
• 创建的日历事件会标记为用户本人操作，完全贴合业务场景的用户预期
• 审计日志可追踪到具体用户的操作，便于后续的问题排查与合规审计

待解决的问题 #

• 依赖用户Azure令牌的生命周期，令牌过期后需用户重新登录获取新令牌（不过可以通过refresh token优化）
• 需要额外开发令牌刷新逻辑，增加少量开发成本

三、推荐方案及优化思路 #

如果你的业务是用户创建自己的Outlook日历事件，优先选委派权限方案，并通过以下方式解决令牌过期问题：

• 用户登录时，额外请求offline_access权限，获取refresh token
• 后台加密存储用户的refresh token，当Azure access token过期时，自动用refresh token换取新的access token，无需用户手动重登
• 你的Web应用自有token中可关联用户的refresh token标识，调用Graph API前先检查Azure令牌状态，过期则自动刷新

如果是应用代表用户批量处理日历事件，且无需用户实时操作，可以考虑应用权限，但必须做严格的权限管控：

• 限制服务主体的权限范围，比如仅允许访问特定用户组的日历
• 用Azure Key Vault存储服务主体密钥，开启密钥轮换机制，避免密钥泄露

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