使用MSAL提供的token cache缓存access token是否安全？

MSAL 保护缓存令牌的核心机制 #

MSAL 针对不同运行平台做了原生的安全适配，默认就对令牌缓存做了加密存储，不需要额外编写代码：

• Windows 平台：默认调用 DPAPI（数据保护应用程序接口） 加密缓存内容，加密后的缓存仅能被当前 Windows 用户、当前应用上下文解密，其他用户或者其他程序就算获取到缓存文件也无法读取明文令牌。
• macOS 平台：默认将令牌缓存存储到系统钥匙串中，依托 macOS 系统钥匙串的权限校验、加密能力保护内容，只有获得授权的应用才能读取对应缓存。
• Linux 平台：默认通过 libsecret 对接系统密钥环实现加密存储，逻辑和 macOS 钥匙串一致，未授权应用无法访问缓存内容。
• 移动端（iOS/Android）：iOS 端默认存储在系统钥匙串，还可配置生物识别校验作为额外访问门槛；Android 端默认存储在 EncryptedSharedPreferences 或系统密钥库中，无 Root 权限的第三方应用完全无法读取缓存。
• 服务端 Web 应用场景：MSAL 会将令牌缓存和用户会话绑定，还可对接服务端自带的数据加密接口做二次加密，不会明文存储在服务端存储介质中。

缓存方案的安全性评估 #

正常使用场景下，MSAL 原生的令牌缓存方案安全性远高于开发者自行实现的令牌存储逻辑，不会被轻易窃取：

• 只要设备没有被越狱、Root，没有被攻击者获取当前用户的最高权限，加密后的缓存就算被攻击者拿到原始文件，也无法解密得到明文令牌。
• 微软官方已经针对各类常见的令牌窃取攻击做了防护，默认方案符合大多数行业的安全合规要求，普通应用直接使用默认缓存即可。

注意：MSAL 的缓存防护无法对抗设备被完全攻陷的极端场景。如果用户设备已经被植入高权限恶意软件，哪怕是系统钥匙串中的内容也存在被窃取的可能，这属于设备级安全问题，不属于 MSAL 缓存本身的设计缺陷。

如果你的应用有更高的安全要求，也可以自行实现自定义缓存逻辑，注意不要将 MSAL 输出的缓存内容明文存储，必须自行做加密处理即可。

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