用户登陆服务
  • 一、密码安全
  • 1、HTTPS通信
  • 2、非对称加密
  • 3、密码加密存储
  • 二、登陆方式
  • 1、手机号登陆
  • 2、邮箱登陆
  • 3、第三方登录
  • 4、扫码登录
  • 三、登陆态管理
  • 1、I/O密集型登录
  • 2、计算密集型
  • 3、综合


内容总结自《亿级流量系统架构设计与实战》

一、密码安全

1、HTTPS通信

HTTPS是身披SSL外壳的HTTP，在HTTP通信链路中利用SSL/TLS建立全信道加密数据包，在请求传输过程中，第三方抓包工具看到的是密文。HTTPS并不能彻底保证密码安全，因为HTTPS的加密、解密行为发生在HTTP层和TCP层之间，一旦服务端经过解密进入HTTP层，数据就变为明文了



2、非对称加密

数据的加密和解密使用两把不同的钥匙，公钥由服务端下发给客户端，用户数据加密；私钥由服务器自己持有，任何经过公钥加密的数据只能被对应的私钥解密。客户端先从服务端获取公钥，之后的对用户提交的密码进行公钥加密，服务端使用私钥解密得到原始密码



3、密码加密存储

使用单向加密算法（不可逆），如MD5、SHA1等。当用户输入密码登陆时，先对输入密码进行加密，然后将加密的密码与数据库中存储的值进行比较，如果一致则认为密码正确


二、登陆方式

1、手机号登陆
  1. 手机号和账号密码登陆
  2. 使用手机号验证登陆
  3. 手机号一键登录：依赖运营商的开放接口，用于获取当前使用的手机号


2、邮箱登陆



3、第三方登录
  1. OAuth2标准：开放的授权标准，允许用户授权乙方应用访问他们存储在第三方平台的信息，而不需要将第三方平台的用户名和密码提供给乙方应用。在授权码模式下，功能是最为完整、流程最严格的，在该标准下，定义了4种角色：
  1. 资源所有者：代表系统第三方登录的终端用户
  2. 资源服务器：第三方登录服务提供商用于存放受保护的用户资源的服务器，访问这些用户资源需要获取访问令牌（Access Token）
  3. 授权服务器：负责验证资源所有者，下发访问令牌
  4. 客户端：乙方应用
  1. 客户端接入第三方登录：如微信第三方登录，允许登录后，微信返回授权码信息给客户端
  2. 服务端接入第三方登录：客户端获取到授权码后传递给后端，服务端使用应用的AppID、AppSecret和授权码用于获取访问令牌，继而完成两边用户共享
4、扫码登录

二维码编码的原始数据是一条跳转至指令和一个UUID

  1. 跳转指令：用于告知客户端，请求跳转到登录确认页面
  2. UUID：用于全局唯一表示这次扫码登录请求，也可以将其理解为二维码的唯一ID

扫码登录记录实现流程，设计用户手机端、网页端、用户登录服务端：

  1. 网页端发起扫码登录方式请求
  2. 网页端向用户登录服务请求生成二维码原始数据（跳转指令、UUID），并展示到网页上
  3. 用户登录服务端将二维码原始数据存储缓存，并记录二维码状态，初始状态为未登录
  4. 用户登录服务端完成二维码初始标记后，将二维码原始数据下发到网页端
  5. 网页端开启本地后台线程，不停的向用户登录服务端轮训当前二维码的扫描状态
  6. 用户手机端打开手机客户端进行扫码，解析二维码，得到UUID并跳转到确认登录页面
  7. 用户手机端点击“确认”按钮登录，用户手机携带UUID请求用户登录服务
  8. 用户登录服务端从缓存中查询UUID是否存在，如果存在，则根据手机客户端请求中的长短令牌获取用户ID，与此同时，修改修改用户登录服务端缓存中二维码的状态，并填入用户ID，即表示当前二维码已经被扫描
  9. 网页端后台线程轮训时，用户登录服务端发现二维码状态被修改，说明二维码已经被用户扫描确认
  10. 用户登录后段服务根据用户ID生成Session数据、长短令牌，然后响应给网页端，下发登陆态信息
  11. 后续用户在网页端的所有请求操作，均携带长短令牌，表示用户已经成功登录，可正常访问网站


三、登陆态管理

1、I/O密集型登录

Session

  1. 客户端成功登录后，在Redis中创建Session，并生成SessionID
  2. 用户登录服务响应客户端时，下发SessionID到客户端的Cookie中
  3. 后续客户端发送请求需要携带SessionID
  4. 服务端根据SessionID去查询用户信息

补充：如果考虑数据安全，可以给SessionID进行一个数字签名的加密

缺点：依赖第三方存储，登录稳定性依赖第第三方中间件



2、计算密集型

Token

用户在登录完成后，服务端会基于用户身份信息加密生成一个安全的令牌返回给客户端，客户端的后续请求在请求头中携带此令牌给服务端，服务端通过验证令牌的合法性来验证用户是否已经登录。如果验证通过，直接解析得到用户信息

缺点：无法主动踢出用户下限，无法统计某时刻处理登录状态的用户信息



3、综合

长短令牌方案（Session+Token）

  1. 客户端发起登录请求
  2. 用户登录服务处理请求，并执行长端短令牌逻辑
  1. 长令牌：生成SessionID，过期时间稍长
  2. 短令牌：生成Token，过期时间稍短
  1. 用户登录服务对长短令牌分别加密得到数字签名后成功响应客户端，并下发长短令牌
  2. 后续客户端请求都会在HTTP请求中携带长短令牌
  3. 服务端收到请求后，先按照短令牌逻辑解析，成功则解析用户，不成功则兜底长令牌解析逻辑；成功则解析用户，并回写长令牌用户信息，不成功则表示登录过气，需要重新登录