【问题标题】:JWT Signing and encoding: overkill or a good ideaJWT 签名和编码:矫枉过正还是个好主意
【发布时间】:2017-01-07 01:52:52
【问题描述】:

上下文:我正在使用 localStorage 通过 jwt 对 node.js 应用程序进行身份验证。

在阅读了很多关于此的意见后,我很困惑。 我有一个使用此代码登录用户的实现:

var payload = jwts.encode({id: user.id}, jwtOptions.secretOrKey);
var token = jwt.sign(payload, jwtOptions.secretOrKey);

这有点简化。但是,我想知道编码是否真的有必要。我应该这样做吗?

var payload = {id: user.id};
var token = jwt.sign(payload, jwtOptions.secretOrKey);

我在有效负载中没有过于敏感的数据,但我将添加可以被看到和利用的声明(用户的计算机已被入侵,localStorage 将显示他们是“管理员”用户)。它不是电子商务网站,但我希望它在上述(可能不太可能)场景中是安全的。

不利的是它使令牌更大(大约 30% 大),因此这会影响性能。考虑到人们现在拥有的带宽,额外的几个字符真的很重要吗

【问题讨论】:

    标签: javascript node.js authentication jwt


    【解决方案1】:

    RFC 7519 Json Web Token 不允许您提出的选项。 jWT 使用 JWS 紧凑序列化,每个部分都必须 base64 url​​ 编码

    JWT 表示为 URL 安全部分的序列,由 句点 ('.') 字符。 每个部分都包含一个base64url-encoded 值。 JWT 中的部件数量取决于 使用 JWS Compact 表示生成的 JWS 使用 JWE 紧凑序列化的序列化或 JWE

    发送没有序列化的 JWT 意味着您需要处理编码。如果您想了解紧凑序列化和扁平序列化之间的区别,请查看 JWS RFC https://www.rfc-editor.org/rfc/rfc7515#page-19

    【讨论】:

    • 感谢 sn-p。几点:令牌仍然是base64编码,它是base64编码编码的“有效载荷”变量。此外,尽管规范声明 jwt 是 base64 编码的,但库允许通过算法使用许多不同的类型:选项部分中的值
    • 是的,在构建 JWT 时,JSON 负载是 base64 url​​ 编码 这是一种标准算法,应用 base64 编码并替换几个字符后
    猜你喜欢
    • 2015-03-09
    • 1970-01-01
    • 2014-08-09
    • 2014-10-31
    • 1970-01-01
    • 2013-01-10
    • 1970-01-01
    • 2017-05-03
    • 2011-06-28
    相关资源
    最近更新 更多