JWT、OOS、Oauth三种登录验证机制

JWT(Json web token)

参考

传统方案：
1) 存储到session（结合redis缓存）
浏览器存储sessesid,服务器集群，
信息存在在后台统一的session服务器
没有分布式架构，无法支持横向扩展
2) 存储到cookie
将验证信息保存在数据库中，后端每次都需要根据token查出用户id，
这就增加了数据库的查询和存储开销。若把验证信息保存在session中，
又加大了服务器端的存储压力。
本质：存储信息在服务端
3）jwt
如果我们生成token遵循一定的规律，比如我们使用对称加密算法来加密
用户id形成token，那么服务端以后其实只要解密该token就可以知道用户的id
jwt中使用对应算法对用户信息加密。
jwt的目的

• 解决跨域
• 多个服务器

JWT实现：

在服务器身份验证之后，将生成一个JSON对象并将其发送回用户
···
{
“UserName”: “Chongchong”,
“Role”: “Admin”,
“Expire”: “2018-08-08 20:15:56”
}
···
客户在请求中发回JSON对象。服务器仅依赖于这个JSON对象来标识用户。
为了防止用户篡改数据，服务器将在生成对象时添加签名

结构由三部分组成

1） JWT头：
{
“alg”: “HS256”,
“typ”: “JWT”
}
它会使用 Base64 编码组成 JWT 结构的第一部分,
2） JWT的主体：
一个JSON对象
{
“iss”: “link JWT”,
“iat”: 1441593502,
“exp”: 1441594722,
“aud”: “www.example.com”,
“sub”: “user”
}
iss（签发者）
exp（过期时间）
sub（面向的用户）
aud（接收方）
iat（签发时间）
它会使用 Base64 编码组成 JWT 结构的第二部分
3） 签名哈希：
Signature 需要使用编码后的 header 和 payload 以及我们提供的一个密钥，
然后使 用 header 中指定的签名算法（HS256）进行签名。
签名的作用是保证 JWT 没有被篡改过
三个部分组合成一个字符串，每个部分用"."分隔，就构成整个JWT对象

• 一般是将它放入HTTP请求的Header Authorization字段

缺点：
一旦JWT签发，在有效期内将会一直有效
JWT的有效期不宜设置太长。对于某些重要操作，
用户在使用时应该每次都进行进行身份验证或手机验证码。
尽量使用 https

OOS单点登录

• 同域名： session+redis(共享)
  注意：cookie不能跨域
• 不同域名：

CAS:在请求CAS Client 时用户必须带有CAS Server
生成的Service Ticket
流程：
1、用户访问CAS Client
2、重定向到CAS Server为验证成功(保存登录信息)用户生成Service Ticket
3、将Service Ticket传递CAS Client、
4、CAS Client向Service Ticket发起验证，成功返回user info

oauth

第三方授权机制

• 参考1
• 参考2

带你区分清楚Authentication,Authorization以及Cookie、Session、Token