在 Oauth OpenID - 授权代码授予类型中，我们将在哪里将“代码”交换为“访问令牌”，为啥？

Posted 2023-02-19

【中文标题】在 Oauth OpenID - 授权代码授予类型中，我们将在哪里将“代码”交换为“访问令牌”，为啥？

【英文标题】：In Oauth OpenID - Authorization code grant type, where will we exchange the "code" for "access token" and why?在 Oauth OpenID - 授权代码授予类型中，我们将在哪里将“代码”交换为“访问令牌”，为什么？

【发布时间】：2021-11-15 01:48:33

【问题描述】：

在 Oauth Open ID - Authorization Code 授权类型流中，

我们将使用client_id = '..'、redirect_uri='...'、response_type='code'、scope='...'、state='...' 调用 Oauth 服务提供商。

然后从 Oauth 服务提供商处，我们将获得 authorization code 而不是令牌。

第一季度。那么下一步是什么？我们是将code 发送到将发生令牌请求的后端，还是我们会从浏览器自身调用Oauth 服务提供者？

第二季度。为什么我们需要这个额外的调用？它解决了什么问题？

Q3收到token后，我们如何在典型的web应用中使用它？

---

p.s：我已经阅读了很多博客，但无法全面了解。你能帮帮我吗？

【参考方案1】：

第一季度。在 2021 年，建议将令牌保留在浏览器之外，因此将代码发送到后端，后端会将其交换为令牌并向浏览器发出安全的 SameSite HTTP Only cookie。 cookie 可以包含经过高度加密的令牌。

第二季度。分离是为了防止发生登录重定向的浏览器攻击。授权代码只能使用一次，但可能会被“浏览器中的人”截获——例如某种插件或恶意代码。如果发生这种情况，则攻击者无法将其交换为令牌，因为还需要 code_verifier 和 client_secret。

第三季度。令牌从浏览器发送到 API，但浏览器无法安全地存储令牌。因此建议在服务器端组件（例如反向代理）中从 cookie 中解压令牌。这限制了令牌在浏览器中被拦截的范围，并且也很好地处理了令牌更新、页面重新加载和多标签浏览。

方法

上述类型的解决方案可以通过两种不同的方式实现：

使用基于网站的技术，该技术可以进行 OAuth 工作并提供 Web 内容 使用 SPA 并以 API 驱动的方式实施 OAuth 工作

不幸的是，浏览器中的 OAuth / OpenID 很困难。在 Curity，我们根据我们的经验提供了一些资源，我们希望这可以为基于现代浏览器的应用程序的整体行为提供一个“全貌”视图：

Code Docs