保护 Azure Active Directory B2C 访问令牌和刷新令牌

Posted 2023-03-07

【中文标题】保护 Azure Active Directory B2C 访问令牌和刷新令牌

【英文标题】：Securing Azure Active Directory B2C Access Tokens and Refresh Tokens

【发布时间】：2019-08-25 15:17:42

【问题描述】：

我遇到过很多文章，这些文章解释了应如何保护令牌以防止未经授权的攻击。 msal.js 的 Microsoft 文档本身指定令牌默认存储在 sessionStorage 中。由于 localStorage 和 sessionStorage 都容易受到 XSS 攻击；你们使用了哪些方法来保护这些令牌。请记住，我希望不要要求我的用户必须经常登录（我需要他们保持登录状态，以便我正在构建一个与我的网络应用程序一起使用的 chrome 扩展程序）。

我创建了两个独立的项目；一个用于我的应用程序 api，另一个用于我的应用程序客户端。我正在使用 .net Core 2.2 和 Angular 7。我读过人们说要使用 httponly cookie 的文章。我在这方面的问题是；这如何与 Azure Active Directory B2C 一起使用？我只是很困惑，所以如果有人能澄清一些东西，我将不胜感激。

【参考方案1】：

所以我得出了一个小结论，即在 SPA（单页应用程序）中通常会给出隐式授权。这意味着没有提供刷新令牌，因为无法将其安全地存储在浏览器中。只有一个访问令牌。访问令牌是短暂的；因此，如果攻击者获得控制权，他只能在指定的时间内执行破坏，并且被破坏的访问令牌更容易检测和缓解。

所以我的方法是使用 localStorage 并努力防止常见的跨站点脚本 (XSS) 攻击。至于 chrome 扩展，谷歌提供了 'chrome.identity' api，它声称可以安全地存储令牌，并提供一种安全的方式来获取和刷新令牌。 （来源：https://www.informationsecuritybuzz.com/articles/security-and-privacy-best-practices-on-building-a-chrome-extension/）

因此，通过 chrome 扩展，您似乎可以维持一个长期会话，但由于 SPA 在浏览器中不存在安全性，因此任何会话都将受限于访问令牌本身的生命周期。将要求用户重新进行身份验证。如果使用社交登录，这对用户来说是相当无缝的。

如果有人发现我在这里所说的内容有任何问题，请随时提出意见；否则，我会将这个问题标记为已回答，以供其他人进一步参考，并在未来提供有关我的经验的更新和问题。