了解了一下 JWT 协议,对于多端统一处理,服务端不用保存,还是蛮看好的。
但是也有疑问,客户端在拿到服务器签发的 JWT 后,如果客户端被拦截,Head 里面的 JWT 不修改,篡改 Body 里面的数据,服务端也会通过。
如果保证这点呢?
1
Miy4mori 2017-07-17 14:56:22 +08:00 via iPhone 3
这点基本不在这种 token 类的考虑内,那是 https 的事。
|
2
hcwhan 2017-07-17 15:11:02 +08:00 via iPhone
jwt 里面可以加上 ip 字段
|
3
RubyJack 2017-07-17 15:18:30 +08:00
这个问题 session 也存在啊,都被中间人了就只能上 https
|
4
lshero 2017-07-17 15:49:00 +08:00
body 的数据没有签名嘛?
|
10
lion9527 2017-07-17 17:36:57 +08:00
所有的加密解密都在服务端完成,客户端为什么要保留秘钥?
|
11
honeycomb 2017-07-17 17:40:59 +08:00
|
12
wancaibida 2017-07-17 18:29:02 +08:00 via iPhone
jwt+jwe 啊
|
13
ChefIsAwesome 2017-07-17 18:58:15 +08:00
|
14
zouqiang 2017-07-17 19:03:53 +08:00
签名肯定得服务端,https 是必须的,+IP,前端的话可以再考虑加 fingerprint
|
15
reus 2017-07-17 19:05:05 +08:00
客户端没有密钥,客户端不能签名,所以客户端不能篡改,就是这么安全。
惟一的问题是,token 泄漏之后,你没法让它失效。 |
17
qclaogui 2017-07-17 19:58:36 +08:00
吓得我又在项目里测了好几遍,“篡改 Body 里面的数据,服务端会通过“?? LZ 可否给个列子, 几遍测下来并没有发现异常
|
18
lemayi 2017-07-17 20:52:12 +08:00
搭个车问一下。前端,不是 app。js 里面没办法存 scret_key,怎么来防止重放攻击呢?
|
19
hantsy 2017-07-17 22:12:39 +08:00
@reus JWT 可以有时效,不要太长。如果结合 OAuth2, 在前端 SPA 中可以自动用 refresh_token 去刷新。
|
20
rrfeng 2017-07-17 22:13:27 +08:00
这个不是 jwt 能解决的问题。是 https 的事。
|
22
Suclogger 2017-07-18 00:49:09 +08:00
客户端的密钥无法保证丢失,用 https 也没用,无法抵御中间人攻击,所以这也是我不愿意使用 jwt 的原因,虽然他很简洁,很适合在微服务环境做认证
|
23
kylin511 2017-07-18 07:38:06 +08:00 via iPhone
可以用 PoP token
|
25
liujun5065 2017-07-18 10:07:49 +08:00
JWT 是方便授权的,只要保证不能被伪造就行了。防劫持那是另外的问题。防中间人劫持可以使用 https。防客户端劫持可以缩短有效时间,可以使用加密硬件,这个需要分情况。支付宝类就可以把时间限制的很短,比如一次交易时间内。v2ex 这种就随便了,设置个一年都没问题。
|
26
ltye 2017-07-18 11:07:28 +08:00
payloads 的签名是在服务端完成的,校验也是,没太看明白篡改有什么用,改的了 payloads 也改不了签名啊,除非渗透了服务器拿到配置里的 secret key
|
27
janyw OP @wancaibida jwe 是个啥?
|