OAuth2工作组发布了一个新的通用安全最佳当前实践文档，其中推荐了一种使用OAuth2在单页应用程序（spa）中从JavaScript调用API的新方法。也就是说，它建议使用带有代码交换验证密钥（PKCE）的授权代码授权来从spa请求访问令牌，而不是最初的OAuth2规范建议在该场景中使用隐式授权。新的指南并不是源于任何新发现的漏洞：如果您对基于当前指南的spa威胁模型感到满意，那么您就没有新的理由进行更新。也就是说，新的指南确实具有显著的优势：强烈建议您考虑它，特别是对于全新的应用程序。如果您选择这种新方法，Auth0端点将支持现在开始使用新方法所需的所有功能。更详细的总结最初的OAuth2规范在spa中引入了隐式授权，作为JavaScript代码从浏览器获取访问令牌和直接调用api的方式。在URL中返回访问令牌（spa的隐式授权所使用的技术）充满了需要显式缓解的已知系统问题。然而，考虑到该项拨款首次推出时浏览器和网络技术的现状，这也是该方案中唯一的游戏。OAuth2工作组决定，现在是时候推荐一种不同的授权来从SPA获得访问令牌了——特别是对于具有PKCEMain驱动程序的公共客户端的授权码授权，似乎是CORS的普遍存在和发送方受限技术的出现。新的建议对授权服务器提出了更多的要求，但是它没有受到在URL中返回访问令牌所固有的问题的影响。这导致客户机所需的缓解逻辑更少。这对像您这样的开发人员有何影响？如果您正在构建一个新的SPA，您应该考虑使用PKCE实现基于授权代码的新指南。下面是更多细节。如果你的投资组合中已经有SPA应用，它们很可能是基于隐式流的——而且几乎可以肯定的是，已经采取措施来缓解这种方法所带来的已知问题。这取决于您是否仍然对现有的缓解措施感到满意，或者是否值得更新代码以遵守新的建议。如果要实现新的建议，则需要验证在应用程序中使用的授权服务器是否支持从JavaScript正确实现授权代码授权所需的功能。如果使用的是Auth0：现有的Auth0 JavaScript sdk都是基于传统的指导。请确保您正在实施适合您的方案的缓解措施。关于这个的更多信息，请稍后在帖子中讨论。Auth0端点支持实现新建议所需的所有特性：您可以在本文后面找到示例代码现在可以通过我们新的Auth0单页appsdk来支持这种新方法。这是简短的版本！文章的其余部分将对此进行深入的阐述，帮助你理解新方法将要解决的问题，你今天有哪些具体的选择，以及可能会出现什么。"Auth0 Principal Architect@vibronet讨论了新OAuth2安全BCP对隐式授权和SPA的影响。"在推特上留言正确看待事物你们中的一些人可能会发现，上面的总结（以及这篇文章）并没有传达出你们在其他讨论中所注意到的紧迫性和惊慌的语气，这些讨论要求立即停止使用隐式流。这可能会给你一些认知上的鞭挞，考虑到自2012年以来，这笔拨款的缺点已经为人所知，而且目前有大量的温泉浴场正在生产中，其中包括被广泛采用并每天都在使用的非常突出的产品，而这些产品并没有受到大的干扰。通常，这些讨论的特点是善意的概括，这是出于保持沟通简洁的必要性以及非发起人可以访问的讨论。此外，作为值得信赖的安全专家，我们倾向于使用"安全"而不是"抱歉"的咒语，而且您会得到通常缺乏细微差别的建议。这有点像是建议你总是去买坦克里的日常用品：我们相信我们给你的建议会保证你的安全，但是你得想办法把你的普锐斯换成一辆坦克，如何为它找到停车位等等……如果你不住在战区，也许实际的风险并不能证明投资的合理性。面临的挑战是，当涉及到标准和安全问题时，通常决定你是否生活在战区的问题归结为阅读长规格说明书，以律师般的专注力关注语言。在这篇文章中，我们将试着为你省去一些这方面的信息，并为你提供可操作的信息，这样你就可以自己决定是否以及何时进行投资。当然，当你有疑问的时候，如果你买得起的话，坦克是一个相当酷的旅程。隐性拨款笼统的陈述表明对隐性补助金作为一个整体的否定是过度概括。OAuth2将隐式授权定义为几乎所有将导致授权服务器（从现在起）直接从授权端点发出令牌的任何流，而不是从令牌端点发出令牌。新指南解决的问题集中在spa上下文中隐式授权的一些特定用途，即访问令牌在URL中返回的用法。其他隐式授权使用不受影响，例如令牌通过POST发送到服务器和/或返回的令牌是id_令牌的那些。为了使用基于回发的web应用程序登录，您可以愉快地向中间层发布id_令牌，如果要在JS代码中使用id_令牌，则可以通过隐式授权为SPA检索id_令牌。隐性补助和水疗对于调用第三方API的单页应用程序，客户机是在浏览器中运行的JavaScript代码，所需的工件是访问API所需的访问令牌。这是给你的一个快速图表。图1：通过隐式授权在SPA中获取访问令牌遵循OAuth2协议语法，客户机将创建一个带有响应类型的请求，该响应类型指示响应应该包含一个访问令牌，例如令牌、令牌id_令牌和代码令牌id_令牌（其中包含id_令牌的组合是常见的OpenId Connect情况）。客户机要么将浏览器重定向到请求的URL，要么使用弹出窗口来做同样的事情——这取决于您选择的SDK作者的口味。这里有一个tokencase的示例请求。请注意，这篇文章中的所有痕迹都是为了清晰起见而编辑的。（1） 得到https://flosser.auth0.com/authorize?观众=https://flosser.com/api/&客户机_id=zugslz6hjgra8lmtophbzckhchcxftmk8&响应类型=令牌&重定向\u uri=http://localhost：3000个/&scope=openid配置文件电子邮件阅读：约会&州=LxfKVRpEwa4lnPEvmx9LbbXSRIVUMaju可以忽略这里的访问群体参数，这是我们在Auth0中用来表示第三方资源的标识符。这并没有改变拨款的实质。对于前面列出的所有response_type值，默认的response_mode（返回请求工件的机制）是fragment–这意味着在成功的身份验证和同意之后，请求的令牌将直接以HTTP片段的形式返回。下面你可以看到一个成功响应的例子。（2） 302 HTTP/2.0地点：：3000/#访问#令牌=eyJ0e[..]ju设置cookie:auth0=s%3AKn[..]Gs；Path=/；Expires=Thu，2018年11月15日19:01:25 GMT；HttpOnly；Secure找到了。正在重定向到您的SDK将期望该形式的响应，并将负责提取令牌并使其可用于您的客户端包含的任何API调用逻辑。问题通过刚刚描述的机制返回访问令牌会为攻击者带来许多机会，必须明确指出这些机会以减少应用程序的攻击面。这里有一个快速列表。有关更多详细信息，请直接参阅最佳实践文档。重定向URI验证不足。如果您选择的AS-of-option没有在运行时请求的重定向URI与之前为客户端注册的重定向URI严格匹配，例如通过接受包含通配符的url，攻击者可能会重定向响应（包含您请求的令牌！）他们控制并获取你的凭证。注意：默认情况下，Auth0强制严格匹配。引用标头的凭据泄漏。如果没有明确的对策（如设置Referer策略头），则在身份验证后立即请求页面可能会将Referer头中的访问令牌泄漏给控制该页面的任何人。浏览器历史记录。带有访问令牌的片段可能会出现在浏览器的历史记录中，因此会受到任何访问它的攻击。代币注入。假设攻击者设法修改一个响应，并将来自AS的令牌替换为从其他地方窃取的令牌，例如为完全不同的用户颁发的令牌。在使用如上所述的隐式授权时，无法检测到发生了这种情况。除了最后一个问题，这里列出的所有问题都有主流的缓解措施。这并不意味着应用这些缓解措施总是容易的，也不意味着每个供应商都能始终如一地这么做，但它们足以使隐性流动成为一种可行的机制，使整个行业在5年内获得spa。把spa中的隐性补助金当作一种治疗头痛的药片，你只能在饱腹的情况下服用，不能与酒精一起服用，但如果使用得当，