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/.
第一个解决方案很简单，但令牌存储在服务器的日志和用户浏览器的历史记录中.
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 tokens are URL-safe when it comes to the syntax. From the 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 中传递不记名令牌:不记名令牌不应该是传入页面 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 服务器日志和其他数据中的 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 值是一个 case-敏感字符串.使用此声明是可选的.
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 声明以及您可能认为相关的一些其他声明(例如 sub 和 exp，例如).
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屋！
