[Day 08] - Spring Boot 实作登入验证(二)(JWT浅析)

第8天，再撑...22天...

我觉得...有必要继续深入探讨JWT

JWT(JSON Web Token)包含了3大部位:header、payload、signature

• header →以base64编码，不加密
  包含:
  1.alg：algorithm(声明使用的加密演算法)
  2.typ：type(类型，一般统一设为JWT)
  ...其余不常见的先略过
• payload →以base64编码，不加密
  包含:
  1.iss：Issuer(签发者，通常放你的URI)
  2.sub：subject(主旨，拿来放可用来识别身分的唯一值，ex：帐号)
  3.exp:expiration time(过期时间)
  ...常见的就这3个，也可以自定义新的key:value加入
• signature → 将 header 跟 payload 两个部位加在一起，以特定的key+演算法产生的字串

其中header的alg是必填项目，主要功用是拿来让Server判断要拿哪种方法解密(有些Server可能设计一个以上不同加密方式)

payload则是主要拿来带使用者验证资讯用的，不过因为JWT上不会加密，仅做base64编码，要注意不能在上面携带机敏资料

此外，虽然exp没规定必带，但是一般都一定会带，不然会难以判断这个token是否该废止

说到这边，我在stackoverflow有看到一则有趣的问题，问的是为什麽他的程序产生的JWT token都是一样的，
看一下这位仁兄产生token的程序是这样写：

JWT.create()
.withIssuer("auth0")
.sign(algorithm);

可以发现他的JWT只带iss，甚至没有user帐号之类的资讯...
不过token都一样的最主要的原因还是没带exp、iat(issued at time)之类会变动的资讯，
因为一直以相同的内容加密，所以才会一直产生相同的signature...

那麽如果在同个一瞬间，同个User一次产生两个JWT token，是不是也会相同的signature?
理论上是，不过在一般情况下同个使用者一瞬间要了两次token的机会不大，
而且就算真的要到了两个相同的token其实风险也不高，
毕竟有设定过期时间，且可以确定虽然会产生相同token，但不可能跟他人相同(因为必定带不同的使用者资讯)，
不过如果真的无法接受相同token的出现，可以在payload再加一个jti的栏位拿来放乱数，进一步降低产生相同token的机会

最後补充一点，
既然signature是透过将header 跟 payload加密产生的，那为什麽JWT不直接只带signiture就好了呢?
为什麽还要带header跟payload?
原因是signature虽然是以header跟payload加密产生的，但是signature本身并不能解密变回header跟payload
signature本身是MAC(讯息认证码)，其功用是拿来验证讯息有没有被窜改，
以jwt来讲，signature是拿来验证header 跟 payload有没有被人乱改的，
因此可以说，header 跟 payload才是主角，是绝不可少的部分

今天就先这样，之後再想想有什麽要补充的