了解 Web 身份验证上下文中的 JSON Web 令牌 (JWT) [英] Understanding JSON Web Token (JWT) in context of web authentication

问题描述

关于 Web 客户端-服务器身份验证上下文中 JWT 的一些陈述:

Some statements regarding JWT in the context of web client-server authentication:

1. JWT 对于中间人攻击并不安全.在安全方面从客户端向服务器发送 JWT 等同于发送散列密码.
2. JWT 可以携带用户详细信息作为有效负载.在不访问数据库中的实际数据的情况下使用这些数据被称为 JWT 功能之一.但是，如果数据库数据发生更改，此 JWT 数据不会失效/更新.
3. 从 2 开始.在某些情况下，JWT 有效负载应针对 DB 进行验证和/或应明智地设置时间戳以在一段时间后使 JWT 失效.

客户必须多次调用 API 才能完成一个工作流的真实示例:用户想知道从 A 到 B 的最短路线的价格.我们使用两种类型的 JWT 一种authJWT"&一个普通的 JWT".

A real world example where a client has to make several calls to APIs to complete just one workflow: a user wants to know the price of the shortest route from A to B. We are using two types of JWTs an "authJWT" & a "normal JWT".

• IF 客户端有一个 authJWT:客户端使用 authJWT 请求 API0(auth API).API0 检查 authJWT 签名 &针对 DB & 的用户数据有效负载时间戳 <2天.返回新的正常"JWT.
  ELSE:客户端请求API0(auth API)，密码为&使用时间戳登录 JWT.API0 检查密码 &登录 DB 并返回 authJWT &正常"JWT.
  在这两种情况下:所有后续 API 都将使用正常"JWT 调用，并且仅通过签名和时间戳验证有效性，但不针对用户数据库.
• 客户端两次请求 API1 以获取位置 A 和位置 B 的搜索字符串的最佳匹配.服务器检查 JWT 签名 &时间戳 <10 秒，并在需要时使用 JWT 用户数据.
• 客户端请求 API2 获取从 A 地到 B 地的最短路径.服务器检查 JWT 签名 &时间戳 <10 秒，并在需要时使用 JWT 用户数据.
• 客户端请求 API3 获取短路路线的价格.服务器检查 JWT 签名和时间戳 <10 秒，并在需要时使用 JWT 用户数据.

• IF client has an authJWT: client requests API0 (auth API) with authJWT. API0 checks authJWT signature & user data payload against DB & timestamp < 2 days. Returns new "normal" JWT.
  ELSE: client requests API0 (auth API) with password & login for JWTs with timestamp. API0 checks password & login against DB and returns authJWT & "normal" JWT.
  In both cases: All subsequent APIs will be called with "normal" JWT and verify validity only via signature and timestamp but not against the user DB.
• Client requests API1 twice to get best match for search string for place A and place B. Server checks JWT signature & timestamp < 10s and uses JWT user data when needed.
• Client requests API2 to get shortest route from place A to place B. Server checks JWT signature & timestamp < 10s and uses JWT user data when needed.
• Client requests API3 to get price for shortes route. Server checks JWT signature & timestamp < 10s and uses JWT user data when needed.

这意味着中间人必须捕获对 API0 的调用才能获得真正的访问权限.捕获正常" JWT 几乎没有效果，因为它会在 10 秒后过期.可能对 API 1-3 的调用甚至可以通过没有 SSL 加密的纯 HTTP 进行 - 但这当然取决于您的用例.在所有情况下，JWT 中的用户数据最好单独加密.

This means that a man in the middle has to catch the call to API0 to get real access. Catching a "normal" JWT has little effect as it expires after 10s. Probably calls to APIs 1-3 could even go over plain HTTP without SSL encryption - but this of course depends on your use case. In all cases the user data in the JWT should better be encrypted separately.

这个设计有什么缺陷?有什么可以改进的?

What flaws does this design have? What could be improved?

推荐答案

你的帖子很大，如果我误解了什么，请见谅

Your post is big, so sorry if I misunderstood something

您似乎在谈论访问令牌和刷新令牌之类的东西.请参阅 this 和 this auth0 文章.Google oauth2 正在使用类似的东西:

It seems you're talking about something like access token and refresh tokens. See this and this auth0 articles. Google oauth2 is using something similar:

• 访问令牌:授权访问受保护的资源.寿命有限.必须保密，由于它们的寿命较短，安全考虑不那么严格.
• 刷新令牌:允许您的应用获取新的访问令牌，而无需重新进行身份验证.寿命长.存放在安全的长期仓库中

• access token: Authorize access to a protected resource. Limited lifetime. Must be kept secret, security considerations are less strict due to their shorter life.
• refresh token: Allows your application to obtain new access tokens without needing to re-authenticate. Long lifetime. Store in secure long-term storage

在此帖子中，您可以查找使用建议:

In this post you can find usage recomendations:

• Web 应用程序:在令牌过期前刷新令牌，每次用户打开应用程序和每个固定时间段(1 小时?)

• Web applications: refresh the token before it expires, each time user open the application and each fixed period (1 hour?)

移动/原生应用程序:应用程序登录一次.刷新令牌不会过期，可以换成有效的 JWT.考虑更改密码等特殊事件

Mobile/Native applications: Application login once. Refresh token does not expire and can be exchanged for a valid JWT. Take in account special events like changing password

回答您的问题，我认为 API0 充当刷新令牌服务器，而 API1、2 和 3 需要访问令牌.使用 HTTPS 避免 ManInTheMiddle，整体使用 API0

Answering your question, I think API0 acts as the refresh token server, and API1,2 and 3 needs access tokens. Avoid ManInTheMiddle with HTTPS, overall with API0

这篇关于了解 Web 身份验证上下文中的 JSON Web 令牌 (JWT)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！