网易用户认证架构设计 | session token | 公开课笔记-01

网易严选中的用户认证架构设计

（一）Session本质及限制分析

1.背景

• 目前是Web2.0交互式网络时代
• HTTP：传输HTML（一种超文本标记语言，侧重静态，不随请求变化而变化），所以HTTP天生缺陷“无状态”，多次请求无关联性，无法请求复用

2.Session+Cookie

• 为实现请求复用，通过二者实现伪有状态
• 业务：转账（登录+转账）

3.本质

• session：服务端对象是Map<userKey,userInfo>，存储在服务端
• Context：也是个Map<sessionId,sessionObj>，用来存储Session
• cookie：也是个Map<JsessionID,sessionID>，客户端存储session的id，下次请求带此id，服务器检索匹配对应session，实现复用

4.限制

• Session之所以基本不再使用，主要还是会侵占服务器的资源(内存)，并且管理起来比较复杂

（二）网易严选的URS系统设计实现

• 积极拥抱无状态，Token，令牌，雷同于各位的身份证。

• 流程：客户端[携带uName,pWord]申请网站地址，网站[携带uName,pWord]去auth-service申请，通过如此间接的，客户端获得token并存储。

• 其中，auth-service不具备私密信息，而是通过crm系统来校验生成token。

• token是字符串，承载基本信息[不含私密信息]，特征“不能随意被伪造”，通过加密保证，其中加密算法重点是“密钥填充”

• 密钥这里涉及“预解析”，为实现预解析，让子系统也持有auth-service的密钥，通过“.dll 和 auth-key”，子系统[携带:服务 组织 公开域名地址]申请接入后能获得相同密钥并且定期更新

生产环境中无状态使用的注意事项

token有效性处理

• 定长器token：token不可变，但是在token中加入了expire过期时间，时间以周为单位
• 普通token：其中包含了过期时间，到期后，或者没有到期可能需要续期。伴随请求进而重新生成token，覆盖之前的token
• 常见问题，就是token在过期时间之内其实会有很多可用token，如何避免？
  例如：加入设备识别、缓存工具。
  还可以使用相对便捷的方式做简单处理，此种处理，需要引入redis等暂存工具。

• 登录时，把用户名作为redis的key，token的唯一标识作为redis的value，过期时间比如设置30min，今
  后不论用户重新登录了多少次，用户的redis对应的token只有一个，且是最后一个。
  TTL：time to live