在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:

智威汤逊在中间袭击中并不安全.从客户端向服务器发送JWT安全性等同于发送哈希密码.
1. JWT可以将用户详细信息作为有效负载. JWT的一项功能是在不访问数据库中实际数据的情况下使用此数据.但是，如果数据库数据发生更改，则此JWT数据将不会无效/更新.
2. 从2开始，在某些情况下，应针对数据库验证JWT有效负载，和/或应明智地设置时间戳，以使一段时间后的JWT失效.

1. JWT are not safe against man in the middle attacks. Sending JWT from client to server security wise equals to sending a hashed password.
2. JWT can carry user details as payload. Using this data without accessing actual data in the DB is cited as one JWT feature. However this JWT data will not invalidate / update if the DB data changes.
3. Following from 2. the JWT payload in some situations should be verified against the DB and / or a timestamp should be set wisely to invalidate the JWT after some time.

一个真实的示例，其中客户必须多次调用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(身份验证API). API0检查authJWT签名和针对DB&的用户数据有效负载时间戳< 2天.返回新的正常" JWT.
  ELSE :客户端请求密码为&的API0(身份验证API)使用时间戳登录JWT. API0检查密码和登录数据库并返回authJWT& 普通" JWT.
  在两种情况下:所有后续API都将使用普通" JWT调用，并且仅通过签名和时间戳验证有效性，而对用户DB则不.
• 客户端两次请求API1，以获取位置A和位置B的搜索字符串的最佳匹配.服务器检查JWT签名&时间戳< 10s，并在需要时使用JWT用户数据.
• 客户端请求API2获得从位置A到位置B的最短路径.服务器检查JWT签名&时间戳< 10s，并在需要时使用JWT用户数据.
• 客户请求API3来获取短线价格.服务器检查JWT签名和时间戳< 10s，并在需要时使用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

您似乎在谈论诸如访问令牌和刷新令牌之类的内容.参见此和 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需要访问令牌.总体上使用API​​0避免使用带有HTTPS的ManInTheMiddle

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屋！