URI中的JWT是不好的做法吗? [英] Is JWT in URI a bad practice?
问题描述
我在Redis中存储了令牌的后备列表(JWT)，并希望使我网站的用户能够以RESTful方式将其令牌列入黑名单.
I have a backlist of tokens (JWT) stored in Redis and would like to enable users of my website to blacklist their tokens in a RESTful way.
我可以:
- 使用DELETE方法构建路线
/sessions/<token> - 使用DELETE方法和在请求正文中发送的令牌来构建路由
/sessions/.
- Build the route
/sessions/<token>with a DELETE method - Build the route
/sessions/with a DELETE method and the token sent in the request body.
第一种解决方案很简单，但是令牌存储在服务器的日志和用户浏览器的历史记录中.
The first solution is simple but the token is stored in the server's logs and in the user's browser's history.
第二种解决方案似乎更好，但我不确定通过发送带正文的DELETE请求不会违反HTTP RFC的幂等性原则.
The second solution seems better but I'm not sure I'm not breaking HTTP RFC's idempotency principle by sending a DELETE request with a body.
在这种情况下，最佳做法是什么?
What's the best practice in this case?
推荐答案
URI中的JWT是不好的做法吗?
Is JWT in URI a bad practice?
当涉及到语法时，
JWT令牌是URL安全的.从 RFC 7519 :
JWT表示为由句点(
.)字符分隔的一系列URL安全部分.每个部分都包含一个以base64url编码的值. [...]
A JWT is represented as a sequence of URL-safe parts separated by period (
.) characters. Each part contains a base64url-encoded value. [...]
但是，当将JWT用作承载令牌时，建议避免在URL中发送它们.请参见 RFC 6750
However, when using JWT as bearer tokens, it's advisable to avoid sending them in the URL. See the following quote from the RFC 6750:
请勿在页面网址中传递承载令牌:不应将承载令牌 传入页面URL(例如，作为查询字符串参数).
Don't pass bearer tokens in page URLs: Bearer tokens SHOULD NOT be passed in page URLs (for example, as query string parameters).
相反，承载令牌应在HTTP消息头中传递，或 采取机密措施的邮件正文.
Instead, bearer tokens SHOULD be passed in HTTP message headers or message bodies for which confidentiality measures are taken.
浏览器，Web服务器和其他软件可能没有足够的安全性 浏览器历史记录，Web服务器日志和其他数据中的URL 结构.如果在页面URL中传递了承载令牌，则攻击者可能 能够从历史记录数据，日志或其他不安全的应用程序中窃取它们 位置.
Browsers, web servers, and other software may not adequately secure URLs in the browser history, web server logs, and other data structures. If bearer tokens are passed in page URLs, attackers might be able to steal them from the history data, logs, or other unsecured locations.
对于问题中提到的情况，您可能不需要发送完整的令牌.您可以为令牌赋予唯一标识符(存储在 jti 声明)，然后仅将令牌标识符发送到服务器.
For the situation mentioned in your question, you may not need to send the full token. You could give the token a unique identifier (stored in the jti claim) and then send only the token identifier to the server.
了解如何在 jti 声明中进行定义上面提到的RFC:
See how the jti claim is defined in the above mentioned RFC:
jti(JWT ID)声明为JWT提供了唯一的标识符.
标识符值的分配方式必须确保
具有相同值的可能性很小
意外地分配给另一个数据对象；如果申请
使用多个发行者，必须防止值之间发生冲突
也由不同的发行人发行.可以使用jti声明
以防止重播JWT. jti值是一种情况-
敏感字符串.使用此声明是可选的.
The jti (JWT ID) claim provides a unique identifier for the JWT.
The identifier value MUST be assigned in a manner that ensures that
there is a negligible probability that the same value will be
accidentally assigned to a different data object; if the application
uses multiple issuers, collisions MUST be prevented among values
produced by different issuers as well. The jti claim can be used
to prevent the JWT from being replayed. The jti value is a case-
sensitive string. Use of this claim is OPTIONAL.
UUID 应该为
A UUID should be unique enough to identify your tokens without collisions.
您也无需将完整令牌存储在黑名单中:仅存储 jti 声明和您可能发现相关的其他声明(例如
You don't need to store the full token in the blacklist either: store only the value of the jti claim and some other claims that you may find relevant (such as sub and exp, for example).
DELETE 请求不应包含正文.因此，您可以使用DELETE /sessions/{id}，其中{id}是令牌的唯一标识符.
DELETE requests shouldn't contain a body. So you could use DELETE /sessions/{id}, where {id} is the unique identifier of your token.
这篇关于URI中的JWT是不好的做法吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
