支持跨域访问,无状态认证
token特点
支持跨域访问:
Cookie是不允许垮域访问的,这一点对Token机制是不存在的,前提是传输的用户认证信息通过HTTP头传输
无状态(也称:服务端可扩展行):
Token机制在服务端不需要存储session信息,因为Token 自身包含了所有登录用户的信息,
只需要在客户端的cookie或本地介质存储状态信息
更适用CDN:
可以通过内容分发网络请求你服务端的所有资料(如:javascript,html,图片等),而你的服务端只要提供API即可
去耦:
不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成,只要在你的API被调用的时候,你可以进行Token生成调用即可
更适用于移动应用:
当你的客户端是一个原生平台(ios, android)时,Cookie是不被支持的(你需要通过Cookie容器进行处理),
这时采用Token认证机制就会简单得多。
CSRF:
因为不再依赖于Cookie,所以你就不需要考虑对CSRF(跨站请求伪造)的防范。
token基本原理
Request
指在一次请求的全过程中有效,即从http请求到服务器处理结束,返回响应的整个过程,存放在HttpServletRequest
对象中。
Session
是用户全局变量,在整个会话期间都有效。只要页面不关闭就一直有效(或者直到用户一直未活动导致会话过期,默认session过期时间为30分钟)
token 认证过程
客户端使用用户名跟密码请求登录
服务端收到请求,去验证用户名与密码
验证成功后,服务端会签发一个 Token,再把这个 Token 发送给客户端
客户端收到 Token 以后可以把它存储起来,比如放在 Cookie 里或者 Local Storage 里
客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
服务端收到请求,然后去验证客户端请求里面带着的 Token,如果验证成功,就向客户端返回请求的数据
因为token是被签名的,所以我们可以认为一个可以解码认证通过的token是由我们系统发放的,其中带的信息是合法有效的
基于JWT的Token认证
JSON Web Token(JWT)
是一个非常轻巧的规范。这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。
JWT的组成:
一个JWT实际上就是一个字符串,它由三部分组成,头部
、载荷
与签名
头部(Header)
用于描述关于该JWT的最基本的信息,例如其类型以及签名所用的算法等。这也可以被表示成一个JSON对象。
然后将其进行base64编码,得到第一部分
{
"typ": "JWT",
"alg": "HS256"
}
载荷(Payload)
一般添加用户的相关信息或其他业务需要的必要信息。但不建议添加敏感信息,因为该部分在客户端可解密
(base64是对称解密的,意味着该部分信息可以归类为明文信息)
然后将其进行base64编码,得到第二部分
{ "iss": "JWT Builder",
"iat": 1416797419,
"exp": 1448333419,
"aud": "www.example.com",
"sub": "aaa@example.com",
"Email": "aaa@example.com",
"Role": [ "admin", "user" ]
}
iss:
该JWT的签发者,是否使用是可选的;
sub:
该JWT所面向的用户,是否使用是可选的;
aud:
接收该JWT的一方,是否使用是可选的;
exp(expires):
什么时候过期,这里是一个Unix时间戳,是否使用是可选的;
iat(issued at):
在什么时候签发的(UNIX时间),是否使用是可选的;
nbf (Not Before):
如果当前时间在nbf里的时间之前,则Token不被接受;是否使用是可选的;
jti:
JWT的唯一身份标识,主要用来作为一次性token,从而回避重放攻击。
签名(Signature)
需要base64加密后的header和base64加密后的payload使用"."连接组成的字符串,
然后通过header中声明的加密方式进行加盐secret组合加密(在加密的时候,我们还需要提供一个密钥(secret),加盐secret组合加密)
然后就构成了jwt的第三部分。
最后,将这一部分签名也拼接在被签名的字符串后面,我们就得到了完整的JWT
注意:secret就是你服务端的私钥,在任何场景都不应该流露出去。
一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了