【问题标题】:Securing Azure Active Directory B2C Access Tokens and Refresh Tokens保护 Azure Active Directory B2C 访问令牌和刷新令牌
【发布时间】: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 一起使用?我只是很困惑,所以如果有人能澄清一些东西,我将不胜感激。

【问题讨论】:

    标签: azure azure-active-directory access-token azure-ad-b2c refresh-token


    【解决方案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 在浏览器中不存在安全性,因此任何会话都将受限于访问令牌本身的生命周期。将要求用户重新进行身份验证。如果使用社交登录,这对用户来说是相当无缝的。

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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-11-06
      • 2019-11-03
      • 2021-08-13
      • 1970-01-01
      • 2018-03-24
      • 2018-02-17
      相关资源
      最近更新 更多