【问题标题】:Access tokens and 2-legged OAuth2访问令牌和 2-legged OAuth2
【发布时间】:2014-04-25 19:43:43
【问题描述】:

我是第一次学习 oAuth2。我将使用它为一些简单的 Web 服务提供身份验证,使用两条腿的方法。

根据我的阅读,流程应该是这样的:Web 服务客户端向 oAuth 服务器提供某种凭证(我正在考虑使用 JWT)。如果凭据有效,则 oAuth 服务器会返回访问令牌。然后,Web 服务客户端在尝试使用 Web 服务端点时提供访问令牌。

这是我的问题,为什么在向端点发出请求时不提供 JWT?为什么 oAuth 的流程是这样构思的。为什么不直接向 JTW 提供端点并将其用于身份验证?获得访问令牌的额外步骤有什么好处?

谢谢!

【问题讨论】:

    标签: oauth oauth-2.0 token 2-legged


    【解决方案1】:

    您当然可以将 JWT 直接提供给 Web 服务。问题是如何以服务信任的方式生成它。

    一个 JWT 是和 access_token,但并非所有 access_token 都是 JWT。

    您的客户端可以发出 JWT,使用密钥(或证书)对其进行签名,然后将其发送到 API。拥有第 3 方(Issuer)的优点是您可以将身份验证与颁发令牌分开。客户端可以通过多种方式进行身份验证(例如 usr/pwd、证书、密钥等),然后使用 JWT 调用您的 API。

    额外的抽象为您提供了更大的灵活性和管理可扩展性。例如:如果您有 1 个 API 使用者,那么您可能只需要一个凭证(或 JWT 或其他)就可以了。如果您计划让许多客户端使用您的 API,那么将该责任交给专门的组件(例如 the issuer)会更有意义。

    OAuth BTW 专为特定用例而设计:代表您将 API 的访问权限委托给另一个系统。您授予对系统 A 的访问权限,以代表您在权限范围内访问系统 B 上的资源。

    【讨论】:

      猜你喜欢
      • 2019-10-25
      • 1970-01-01
      • 2017-08-28
      • 2018-07-17
      • 1970-01-01
      • 2011-03-07
      • 2016-07-07
      • 2016-03-05
      • 2012-08-13
      相关资源
      最近更新 更多