身份认证session,token,jwt分析

身份认证方案

`
常见的认证方案为session,token,jwt(jsonwebtoken)

背景

由于在http协议刚出现时,web基本上就只有文档的浏览功能,不需要记录谁在某段时间浏览了什么文档,没有上下文,每次请求都是全新的http请求,也因http协议的设计也是无状态的,但随着交互式web应用的兴起,必须把每个人区分开,比如电商网站谁购买了什么东西.所以此时服务器必须用会话来跟踪用户的状态和身份.所以就出现了session,通过客户端传来的session标识获取服务端session数据识别用户和获取用户信息.但随着web的继续发展,session扩展复杂,服务端负担大,无法满足给予第三方应用选择性权限需求等问题慢慢出现.所以就出现了token和jwt,token和jwt都是存储在客户端,服务端通过其中的签名进行身份认证.其中jwt相当于token的升级版,定义了一个json格式的token标准.

原理

Session(会话)

是传统web应用中常使用的身份认证方式,当用户登录后，服务器会为其创建一个唯一的会话ID，并将该ID存储在服务器端,然后随着响应将ID返回给客户端。客户端在后续请求时会将会话ID发送给服务器,，服务器通过该ID来识别用户并维护其状态。会话通常使用Cookie或URL重写来传递会话ID。

常见应用场景:传统web服务身份认证,简单web服务身份认证

分布式web服务身份认证样例：
1.用户登录服务
2.服务器生成会话ID和会话数据
3.将会话ID和会话数据以k-v格式缓存在Redis集群,并设置过期时间为1天
4.将会话ID存储在响应的Cookie中,随着响应返回给客户端
5.用户继续访问服务,服务器获取请求中的会话ID获取Redis中的会话数据,并重新设置Redis中该会话数据延长一天.

Token(令牌)

令牌本质是一个代表用户身份的字符串,常用于身份认证或授权.当用户登录后,服务器会随着响应将一个令牌返回给客户端.客户端在后续请求时将将令牌作为身份凭证发送给服务器,服务器会验证令牌的有效性,并根据其权限进行相应的操作

常见应用场景:服务内部之间身份认证,第三方应用身份认证

内部服务A和B认证实现样例:
1.服务A和服务B事先配置对齐好seed(可存储在配置中心)
2.确定token生成算法为:md5(seed+随机值)+明文随机值
3.服务A调用服务B接口前,生成tokenA,并随请求发送给服务B
4.服务B收到请求取出token,通过请求给的随机值生成tokenB
5.检查tokenA和tokenB是否相等来判断请求是否合法

注意:seed是配置文件配置随便一个字符串,timestamp是发送请求时的时间戳,md5是哈希摘要算法

JWT(Json Web Token)

JWT是一种基于JSON的开放标砖(RFC 7519)的令牌.它由三部分组成:header(头部),payload(载荷),sigature(签名),头部包含描述令牌类型和算法的元数据，载荷包含实际的用户数据，签名用于验证令牌的完整性和真实性.相比常规令牌会将许多数据存储在payload中,而不是数据库中.比如可以直接通过jwt检查权限等.这无疑比常规token更节省了时间和空间.

常见引用常见:单点登录身份认证,复杂web身份认证

单点身份认证(包含登录服A,业务服B)样例
1.服务A和服务B事先配置对齐好secretValue
2.用户登录服务A
3.服务A生成JWT:header+payload+sigature(md5(header+payload+secretValue))
4.服务A获取预先生成的RSA加密的私钥,对JWT进行加密(防止字符串中带特殊字符还需要base64url编码,将JWT二进制数据编码成不带特殊字符的字符串)
5.加密后的JWT存储在请求头自定义字段随响应返回给客户端
6,用户携带JWT访问服务B
7.服务B获取RSA的公钥,解密获取JWTA
8.检查payload中过期时间字段是否过期
9.通过md5(header+payload+secretValue)生成sigatureB
10.进行签名认证,两个签名相等且没过期则认证通过

对比

1.开销：JWT是无状态的,不需要维护会话信息,减轻了服务器的负担。且由于包含了用户的身份信息，也避免了多次查询数据的开销,但增加了网络IO开销,所以载荷往往不能太大.
2.扩展：JWT由于没有依赖于服务器的存储会话信息，可以更简单地进行水平扩展,会话需要考虑扩展的服务器能不能获取到会话信息等问题.
3.安全:会话信息往往在所有服务器上都能获取和修改,而JWT可以在生成之后再进行一个非对称加密,私钥仅由登录服保管,其它服只能获取到公钥对JWT解密,大大降低JWT生成方法泄露概率.但JWT存在无法废弃的问题,所以JWT设置的过期时间往往不能过长,且需要设置黑名单当有需要JWT提前过期时,需要将它存进黑名单避免继续被使用.
4.跨域支持：可以通过将JWT放在请求头中,在不同的域之间进行传递，方便构建分布式系统。会话ID一般存储在Cookie具有不可跨域性,
5.第三方授权支持:除了跨域问题还要考虑权限问题,Token能根据事先配置不同的权限来生成不同的令牌,使第三方认证后获取的权限受限.