用户认证信息存放策略探讨

本文就用户认证信息存放策略做简要的探讨，用以说明当前的选择思路和未来的扩展方案。

 

背景介绍

用户认证

用户认证，核心是两个步骤

• Authentication：认证，指的是验证用户的身份，即一般通过账号密码登录的身份认证过程

• Authorization：授权/鉴权（鉴权比较好理解），指的是在用户登录之后，鉴定其所拥有的权限

注意，上述browser不一定非得是浏览器，移动APP客户端也可以；

server也做了归一，实际应用中，一般会区分为认证服务和应用服务。这点很重要，也是策略的一个衍生点。

 

为啥需要认证信息存储

从我们的实际使用中，登录认证，是比较低频的，即你不在登录状态，需要重新输入用户的账号密码做重新认证。

 

我们本文要探讨的核心是鉴权这个步骤，因为用户的操作非常的频繁，从哪里获取数据来鉴定用户的权限是高频场景，所以需要针对性给到评估方案。

最核心的前提背景是：

由于http协议是无状态的，每一次请求都无状态。当一个用户通过用户名和密码登录了之后，他的下一个请求不会携带任何状态，应用程序无法知道他的身份，那就必须重新认证。

因此我们希望用户登录成功之后的每一次http请求，都能够保存他的登录状态，并且能够在各个应用服务上快速的鉴定其权限。

 

 

基于上面这样的背景，就存在多种策略来存储用户认证信息。

有哪些存储位置

既然涉及到数据存储，无非就看看有哪些参与方，如上表述，核心有

• 客户端（包括browser、移动APP等）

• 应用服务

• 认证服务

有意的梳理了上述的顺序，本质上每个参与方都是可与走数据存储的，只是性能、安全、数据一致性等评估和考量了。

 

各类方案对比

市面上有很多中方案和协议或标准，除却各种安全认证和分发方式外，其核心本质就是存储位置策略问题，根据不同的存储方案，目前主流的用户认证方法有基于token和基于session两种方式。

其本质就是根据认证是放在客户端侧还是服务端侧，如果是客户端侧为token机制，服务端侧为session机制。

我们先阐述这两种机制的特点及差异，再展开讨论针对不同机制的优化方案。

session机制

与session并存的是cookie，cookie+session的存在主要是为了解决HTTP这一无状态协议下服务器如何识别用户的问题。

其原理就是在用户登录通过认证后，认证服务会对用户做认证逻辑，如果认证通过，生成相应的sessionID，同时拉取用户相关的权限信息，统一缓存在session对象中（该session对象有多种缓存策略，后续详述）。

如此，后端通过response返回给前端，带着setCookie设置，客户端设定Cookie，核心是保存sessionID。在客户端再次发起请求时，默认会自动通过request携带cookie都后端&