blog
blog copied to clipboard
eddycjy
posts/go/gin/2018-02-14-jwt/
@FicowShen @jmy10241024 HS256是对称加密，应该是这个原因不需要存储到数据库
你自己去试试就知道了。我按照他的代码生成了字符串之后去进行base64解码，所有信息都一览无遗的~
可以加入双向验证，服务端生成的token在二次加密（不可逆），然后返回至客户端，客户端拿到token再去跟服务器交流会话，服务器按对应的token在本地查找是否存在，然后在做对应的解析
jwt的payload部分确实不应该存放敏感信息，因为该部分是客户端可解密的。但是即使解密也分发不了token，因为少了secret私钥，secret是存储在服务端。
记录一个生成Token的错误：如果生成时报key is of invalid type先看一下util/jwt.go用的tokenClaims := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)是不是HS256的，千万不要粗心写成ES256！！！(前车之鉴QAQ)
顺带贴一个在debug的时候发现的另一个小坑，即func (*jwt.Token).SignedString(key interface{})中的key要用[]byte
https://github.com/dgrijalva/jwt-go/issues/65
用户名和密码直接用来生成token确实不太好，可以用用户ID和用户名去生成。楼上说base64解码，比较搞笑～
看一下这个图：
搞笑吧~
是不是没设置jwtSecret，如果设置了应该会签名加密才对
用户名和密码直接用来生成token确实不太好，可以用用户ID和用户名去生成。楼上说base64解码，比较搞笑～
看一下这个图：
搞笑吧~
是不是没设置jwtSecret，如果设置了应该会签名加密才对
我仔细看了看jwt的文档，发现你是对的，就不应该把敏感信息放在jwt里
大家何必纠结，这只是一个demo演示，师傅领进门，修行在个人，既然知道哪里可能出现安全隐患，就可以自己去解决，这样有目的的学习进步更大。
用户名和密码直接用来生成token确实不太好，可以用用户ID和用户名去生成。楼上说base64解码，比较搞笑～
看一下这个图：
搞笑吧~
jwt不是普通的base64，推荐用这个解析 参考资料：https://jwt.io/introduction/ 解码工具：https://jwt.io/#debugger
本人：前端同学 （三年前端+1年IOS native 开发 目前在newegg） 观点：
- 真实业务中 jwt里确实不应该放 密码等隐私问题
- 煎鱼打算 的golang demo是带你入门为目标的，真实 场景下 还需要考虑很多，比如 POST PUT 的参数应该放 body中，authToken应该放在请求头中 ，jwt签名的时候需要把ini文件中的，盐🧂 加进去
- 对于多用户登录的系统 jwt应该是放到redis中去维护的
以上是我工作中 和我司的落地运用
token 分有状态和无状态两种 jwt就是无状态的 意思就是无法通过一个状态将token失效，无状态的token作用就是为了减少对数据库查询减少数据库压力，不进行token存储
