时间戳

首页 > 解决方案 > OAuth2.0 和 OpenID 良好实践

web - OAuth2.0 和 OpenID 良好实践

问题描述

我最近对 ​​Oauth2.0 和用于管理 OAuth 并未真正处理的身份验证部分的薄“层”openID 感兴趣。我读过一些文章，有时是矛盾的，并观看了一个关于它的非常好的会议：https ://www.youtube.com/watch?v=0VWkQMr7r_c 。不幸的是我不在观众席，所以没有机会问我的问题。希望有人可以在这里回答他们：

OAuth2.0具体问题：

  1. 在授权码流程中使用了前后通道的概念。据我了解，前端通道用于重定向到授权服务器，然后使用授权码返回客户端应用程序。然后这是反向通道的责任，通过向授权服务器请求代码、client_id、client_secret 和 state 参数，将接收到的代码与 access_token 交换。

    到目前为止一切正常，但是当后台通道收到 access_token 时，我的应用程序应该如何处理它？我的意思是，最后，我的客户端（所以我的应用程序）由前端（比如 VueJs）和后端（比如 NodeJs）组成。然后在前端，用户（资源所有者）单击一个按钮，该按钮应该在资源服务器上获取一些信息。为此，前端需要使用 Authorization 标头中的 access_token 向资源服务器发送请求。但是 access_token 是敏感数据，所以前端不应该知道它的权利（只有我的后端知道它对吗？）。

    我是否需要将后端用作代理，并且来自前端的每个需要 access_token 的请求都应首先通过我的后端，该后端会将 access_token 添加到 requet 标头，然后将其转发到资源服务器？或者我可以将 acces_token 存储在 cookie 中，以便我的前端可以直接使用它？前者不可避免地会导致我的后端使用某种会话 cookie 来获取关联的 access_token，但是安全性再次受到影响，因为我的会话 cookie 位于前端通道上，并且它允许，就像关联的 access_token 一样，查询资源服务器（从前端的角度来看）。后者似乎与授权代码流的目标相矛盾（从浏览器中隐藏 access_token），但我已经看到一些应用程序这样做......

    简而言之，我看不出如何从反向通道概念中受益，因为在某些时候，对资源服务器的请求来自前端。

  2. OAuth2.0有一个刷新令牌的概念，它的寿命往往比访问令牌长，用于获取一个新的acces_token，而无需经过重定向到授权服务器、获得用户同意等过程。但是，如果我可以只使用一个刷新令牌（例如一年）并获得一个新的 access_token ，那么拥有短暂的 access_tokens 又有什么意义呢？短命令牌只是出于安全原因“短命”，但 refresh_token 似乎绕过了那些短命令牌的目标。因此，为什么不为 ... 另一个 refresh_token 设置一个 refresh_token 呢？不确定我是否清楚，但在我看来，刷新令牌可以被长期访问令牌替换（安全影响是相同的）。

OpenID 特定问题

  1. 如果我理解正确，OpenID 用于管理身份验证部分，并添加了一些关于 OAuth2.0 的“标准”（标准范围名称，一个端点，可用于获取授权支持的所有端点/代码流/范围的列表服务器等..)。所以在某些时候授权服务器会返回给客户端一个 id_token。当我说这个令牌不敏感并且可以存储在 cookie 中时，我说得对吗？

  2. 如何在客户端应用程序上获取 id_token 的标准方法。查看 RFC https://www.rfc-editor.org/rfc/rfc6749#page-19我只能看到 3 种响应类型（代码、令牌或注册的扩展值，不要问我）。OpenID 似乎添加了另一种响应类型：id_token（请参阅https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationExamples）。作为客户，如果我想要访问令牌和 id 令牌，我是否需要：

    • 发送 2 个单独的请求，一个带有 response_type=code 另一个带有 response_type=id_token
    • 仅发送一个带有 response_type=code 的请求，但在请求的范围内添加 openID
    • 仅发送一个响应类型=代码 id_token 的请求，范围内有/无 openID
    • ETC...

这已经是一个很长的话题了，所以我将在这里停止我的问题。提前感谢您的回答。

标签： weboauth-2.0openid

解决方案

一些答案，虽然这些有点固执己见：

Q1a。5 年前的 WEB UI

首次设计授权代码流时，通常使用服务器端 Web 应用程序和 cookie。然后在服务器端处理部分登录流程。但是，这种方法可能与现代 Web UI 目标相冲突。

Q1b。今日网页界面

如今，在移动 UI 中使用令牌被认为是标准的，而 Web UI 几乎可以工作。这有很多简单的好处，所涉及的步骤在我的Messages Blog Post中进行了总结。

Q1c。网页界面安全测试

有些人将安全性评估为 cookie v 令牌，我认为这有点简单化。使用基于令牌的单页应用程序，您需要确保没有跨站点脚本漏洞。

Q2。WEB UI 和令牌刷新

Web UI 的标准解决方案是使用基于 Open Id Connect prompt=none参数的 iframe 令牌更新解决方案，如本页所述。

Q3。身份代币

如今，Web 和移动 UI 都可以使用授权代码流 (PKCE)。ID 令牌可能会由 UI 中的安全库验证，但您通常不会在代码中大量引用 id 令牌（如果有的话）。

Q4。响应类型

使用 response_type=code，然后您将获得 id 令牌作为授权代码授予消息的一部分，如上面的消息博客文章中所述。

连接运动部件

如果对纯 SPA / cookieless 方法感兴趣，可以看看我的教程，其中包括一个可以在 PC 上运行的代码示例。

推荐阅读