API网关设计（一）之Token多平台身份认证方案(转载)

原文：https://segmentfault.com/a/1190000018535570?utm_source=tag-newest

概述

今天咱们面对移动互联网的发展，系统一般是多个客户端对应一个服务端。
客户端统一通过F5或者Nginx代理转发到API网关，最后发送到服务API。
如下图架构图所示

这个过程当中就存在多个很明显需要做的事，如下列表

身份认证（登陆以及会话级用户认证）
权限认证（当然是认证用户身份之后，确认是否有权限调用API）
调用频率控制（限流算法如计数，滑动窗口，漏桶，令牌桶）
负载算法（如权重，均衡，例外再比如灰度发布都是同一个思路）

而咱们今天主要讲的了就是身份认证这一块具体怎么设计Token，在前一篇文章中已经描述过整体的登陆逻辑，不清楚的同学可以看一下。

Token设计

如今的系统不可能存在一个token走到底打通所有系统，为啥这么说？
由于不同的客户端，会存在不同的认证场景。
咱们具体看一下分析过程

认证场景

客户端以下几点用户认证的场景

移动端登陆，会话API调用
web端登陆，会话API调用
移动端扫码登陆web（如微信扫码）
移动端授权登陆（如微信授权）

而通过客户端的认证场景，咱们又能具体推理出功能级别的具体场景如下

客户端记住用户密码免登陆认证
API调用的会话级别认证
移动端已登陆授权web端免密登陆

Token设计要点

通过上面的认证场景才能不难得出如下结论

多层级Token
Token之间可向下授权
Token使用频率
Token失效时间

级别划分 1～3 分别为低中高

Token	名称	级别	使用频率	有效期	保密级别	变化成本
webtoken	web端token	3（持久化）	1	>=1天	3	3
mobiletoken	mobile端token	3（持久化）	1	>=1天	3	3
sessiontoken	会话token	2（会话级）	3	分钟级别	3	1
accesstoken	API认证token	1（短暂认证）	3	秒级	2	1

再具体看一张token层级架构图

为啥要将token分这么多类型了？
咱们先根据上图捋一下思路具体如下几步

用户名和密码认证获取webtoken或者mobiletoken
用户登原先存在webtoken或mobiletoken可以拿到sessiontoken
通过sessiontoken可以去拿去短暂的accesstoken
通过accesstoken可以调用API

层级token优势

通过上面咱们可以看出来最终调用api是通过accesstoken，那么咱们为什么还需要设计
多层token了？主要有以下几个原因

不同的客户端对于免登陆的要求是不一样的，比如web端输入一个用户名密码或者通过手机接受一个验证码是很方便的事情，所以token时间不会存放特别长。但是对于移动端来说，对于用户体验比较好的情况就是随时随刻都是登陆状态，输入一次密码最好能用个大半年。
安全性考虑这一点是由于第点的原因导致，由于webtoken或者mobiletoken存储在客户端的时间较长。如果调用频率很高，及其容易导致被抓包获取到黑客手中。因此引入了会话级别token通过持久化在客户端的mobiletoken等去获取。会话token的特点就是调用频率高，失效时间快，就算被被人拿到了不会造成奔溃式的问题出现。
统一后台api调用控制，accesstoken的存在是真正调用api的token，也是通过sessiontoken获取。为了不同客户端统一接入api实现，如果acesstoken不统一。那代码层面实现又全部耦合到了一起，如果是统一的就可以将代码抽出来一个层级放在网关统一实现。

综合上面可以总结出来的优势有如下几点

解耦系统（accesstoken网关之后的系统可以任意部署）
提高系统扩展性（可以接入不同性质的客户端）
层级清楚便于维护（token分层代码，便于独立维护）

token安全控制

首先咱们得明白一个道理对于任何登陆系统来说根本就不存在百分百的安全，唯一可以做到的就是提高破解成本。具体的安全控制方法我的总结如下

使用https哪怕被抓包看到的也是加密数据，除非客户端和服务端都被黑了。这尼玛这人这么优秀，干点啥不好。。。
根据业务要求设置不同token失效时间，token失效时间越短越安全，用户体验也会有所下滑
token可以根据动态加密算法以及密码定时更新，然后通过cookie打回客户端
移动端可以获取设备id以及ip，当短时间内出现同一账号不同设备请求，及时失效所有token，或者发出告警短信给用户，权限级别较高的操作禁用。
移动端加入人脸或者指纹识别

完整架构图