【问题标题】:Workflow of JWT authenticationJWT认证工作流程
【发布时间】:2014-01-28 05:38:47
【问题描述】:

我的任务是为客户创建一个面向服务的生态系统。整个事情将基于 REST 并内置在 ASP.NET 中,但我的问题与技术无关。我们希望有一个集中的身份验证服务,它发布环境中其他服务信任的 JWT 令牌和声明。

我的问题是 - 网络客户端(浏览器)请求的第一件事是什么?我见过的所有图表(我将尝试添加几个示例链接)看起来好像客户需要自我意识并意识到他们在制作第一个之前需要一个令牌对功能性 REST 服务的请求,这对我来说似乎很笨拙。

我希望它的工作方式是他们只是尝试访问受保护的资源,但是没有身份验证令牌与我的 REST 服务向他们询问用户/密码的请求,然后将身份验证委托给我的身份验证服务。所以:

  1. 浏览器请求 REST 服务上的受限资源
  2. REST 服务返回 401
  3. 浏览器收集凭据,发送到同一个 Web 服务
  4. REST 服务连接到身份验证服务,传递来自客户端请求的 Auth 标头
  5. Auth 服务创建 JWT 令牌并将其返回给 REST 服务
  6. REST 服务验证 JWT 并将 Auth 标头替换为 JWT 令牌
  7. JWT 令牌为后续请求保留,直到 expy 设置

...我完全不在乎这个吗? Web 客户端是否需要知道涉及到一个单独的身份验证服务并在那里发出一个请求以获取他们的 JWT,然后对通过 JWT 的 REST 资源发出第二个请求?这对我来说似乎很笨拙,我希望不是这个想法。

另外,另一个 n00b 问题 - JWT 令牌是否由 Web 客户端自动保存并随每个请求重新发送,因此我不必每次都通过身份验证服务步骤?这就是过期设置的目的吗?

TIA。

请参见此处的图 1,了解我的意思的示例:http://msdn.microsoft.com/en-us/library/hh446531.aspx

【问题讨论】:

    标签: asp.net rest authentication soa jwt


    【解决方案1】:

    从你的最后一个问题开始会让其余的答案更清楚:

    • “...是由 Web 客户端自动保存并随每个请求重新发送的 JWT 令牌。” - 想法是发出一次 JWT,将其发送给客户端,以便客户端可以保存并继续发送每个后续请求。这样,您的前端应用程序将只发送一次用户名和密码,然后使用 JWT 进行身份验证。您必须使用浏览器存储(本地或会话)或 cookie(旧浏览器的常见后备)来存储 JWT。
    • "...Web 客户端是否需要知道涉及到单独的身份验证服务..." - 您需要将用户名和密码发送到服务才能发布 JWT。您可以只使用一个请求来实现它,但是您需要将凭据发送到服务(由用户提供),接收 JWT 作为响应的一部分并存储它(如上所述)。根据要求和实施情况,在单独的请求中执行此操作可能会更容易。

    【讨论】:

      猜你喜欢
      • 2020-12-05
      • 2016-03-10
      • 2020-07-15
      • 2017-11-02
      • 2021-04-30
      • 2021-09-20
      • 2018-11-06
      • 1970-01-01
      • 2021-03-05
      相关资源
      最近更新 更多