菜菜,上次你讲的cookie和session认证方式,我这次面试果然遇到了


结果怎么样?


结果面试官问我还有没有更好的方式?


看来你又挂了


别说了,伤心呀。到底还有没有更好的方式呢?


你猜?




把认证信息保存在客户端,关键点就是安全的验证,如果能解决认证信息的安全性问题,完全可以把认证信息保存在客户端,服务端完全无认证状态,这样的话服务端扩展起来要方便很多。关于信息的安全解决方案,现在普遍的做法就是签名机制,像微信公众接口的验证方式就基于签名机制。


基于token的验证方式也是现代互联网普通使用的认证方式,那它有什么优点吗?
1. 支持跨域访问,Cookie是不允许垮域访问的,这一点对Token机制是不存在的,前提是传输的用户认证信息通过HTTP头传输.
2. 无状态:Token机制在服务端不需要存储session信息,因为Token自身包含了所有登录用户的信息,只需要在客户端的cookie或本地介质存储状态信息.
3. 解耦 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成,只要在你的API被调用的时候,你可以进行Token生成调用即可.
4. 适用性更广:只要是支持http协议的客户端,就可以使用token认证。
5. 服务端只需要验证token的安全,不必再去获取登录用户信息,因为用户的登录信息已经在token信息中。
6. 基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库(.NET, Ruby, Java,Python,PHP)和多家公司的支持(如:Firebase,Google, Microsoft).
那基于token的认证方式有哪些缺点呢?
1. 网络传输的数据量增大:由于token中存储了大量的用户和安全相关的信息,所以比单纯的cookie信息要大很多,传输过程中需要消耗更多流量,占用更多带宽,
2. 和所有的客户端认证方式一样,如果想要在服务端控制token的注销有难度,而且也很难解决客户端的劫持问题。
3. 由于token信息在服务端增加了一次验证数据完整性的操作,所以比session的认证方式增加了cpu的开销。
但是整体来看,基于token的认证方式还是比session和cookie方式要有很大优势。在所知的token认证中,jwt是一种优秀的解决方案


头部

{
"alg": "HS256",
"typ": "JWT"
}
Payload

iss (issuer):签发人
exp (expiration time):过期时间
sub (subject):主题
aud (audience):受众
nbf (Not Before):生效时间
iat (Issued At):签发时间
jti (JWT ID):编号

{
"Name":"菜菜",
"Age":18
}
Signature

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)


1. 客户端携带用户的登录凭证(一般为用户名密码)提交请求
2. 服务端收到登录请求,验证凭证正确性,如果正确则按照协议规定生成token信息,经过签名并返回给客户端
3. 客户端收到token信息,可以保存在cookie或者其他地方,以后每次请求的时候都携带上token信息
4. 业务服务器收到请求,验证token的正确性,如果正确则进行下一步操作

本文来源于互联网:程序员过关斩将–更加优雅的Token认证方式JWT