大神简述基于token多平台身份认证架构设计，太赞了( 二 ) 小Hub领读：很多人都知道toke

会话 token 可以生成和刷新延长 access_token 的生存时间

access_token 可以生成生存周期最短的用于授权的二维码的 token

使用如上的架构有如下的好处：

良好的统一性。可以解决不同平台上认证 token 的生存周期的归一化问题
良好的解耦性。核心接口调用服务器的认证 access_token 可以完成独立的实现和部署
良好的层次性。不同平台的可以有完全不同的用户权限控制系统，这个控制可以在会话层中各平台解决掉

4.1、账号密码广义的账号 / 密码有如下的呈现方式:

传统的注册用户名和密码
应用程序的 appid/appkey

它们的特点如下：1、会有特别的意义
比如：用户自己为了方便记忆，会设置有一定含义的账号和密码。
2、不常修改
账号密码对用户有特别含义，一般没有特殊情况不会愿意修改。而 appid/appkey 则会写在应用程序中，修改会意味着重新发布上线的成本
3、一旦泄露影响深远
正因为不常修改，只要泄露了基本相当于用户的网络身份被泄露，而且只要没被察觉这种身份盗用就会一直存在
所以在认证系统中应该尽量减少传输的机会，避免泄露。
4.2、客户端会话 token功能：
充当着 session 的角色，不同的客户端有不同的生命周期。
使用步骤：
用户使用账号密码，换取会话 token
不同的平台的 token 有不同的特点：
Web 平台生存周期短主要原因：

环境安全性：由于 web 登录环境一般很可能是公共环境，被他人盗取的风险值较大
输入便捷性：在 PC 上使用键盘输入会比较便捷

移动端生存周期长主要原因：

环境安全性：移动端平台是个人用户极其私密的平台，它人接触的机会不大
输入便捷性：在移动端上使用手指在小屏幕上触摸输入体验差，输入成本高

4.3、access_token功能：
服务端应用程序 api 接口访问和调用的凭证。
使用步骤：
使用具有较长生命周期的会话 token 来换取此接口访问 token 。
其曝光频率直接和接口调用频率有关，属于高频使用的凭证。为了照顾到隐私性，尽量减少其生命周期，即使被截取了，也不至于产生严重的后果。
注意：在客户端 token 之后还加上一个 access_token ，主要是为了让具有不同生命周期的客户端 token 最后再调用 api 的时候，能够具有统一的认证方式。
4.4、pam_token功能：
由已经登录和认证的 PC 端生成的二维码的原始串号（Pc Auth Mobile）。
主要步骤如下：

PC 上用户已经完成认证，登录了系统
PC 端生成一组和此用户相关联的 pam_token
PC 端将此 pam_token 的使用链接生成二维码
移动端扫码后，请求服务器，并和用户信息关联
移动端获取 refresh_token(长时效的会话)
根据 refreshtoken 获取 accesstoken
完成正常的接口调用工作

备注:
生存周期为 2 分钟, 2 分钟后过期删除
没有被使用时, 每 1 分钟变一次
被使用后, 立刻删除掉
此种认证模式一般不会被使用到
4.5、map_token功能：
由已经登录的移动 app 来扫码认证 PC 端系统，并完成 PC 端系统的登录（Mobile Auth Pc）。
主要步骤：

移动端完成用户身份的认证登录 app
未登录的 PC 生成匿名的 map_token
移动端扫码后在 db 中生成 map_token 和用户关联（完成签名）
db 同时针对此用户生成 web_token
PC 端一直以 maptoken 为参数查找此命名用户的 webtoken
PC 端根据 webtoken 去获取 accesstoken
后续正常的调用接口调用工作

备注:
生存周期为 2 分钟, 2 分钟后过期删除
没有被使用时, 每 1 分钟变一次
被使用后, 立刻删除掉
5、小结与展望本文所设计的基于 token 的身份认证系统，主要解决了如下的问题：

token 的分类问题
token 的隐私性参数设置问题
token 的使用场景问题
不同生命周期的 token 分层转化关系

本文中提到的设计方法，在应用层中可以适用于且不限于如下场景中：

用户登录
有时效的优惠券发放
有时效的邀请码发放
有时效的二维码授权
具有时效手机 / 邮件验证码
多个不同平台调用同一套 API 接口
多个平台使用同一个身份认证中心

【大神简述基于token多平台身份认证架构设计，太赞了】至于更多的使用场景，就需要大家去发掘了。