跨平台跨端的登录流程及其安全设计

一、登录流程

1.1、登录流程时序图

1.2、三方App 登录

1.3、请求的路由守卫

二、注册流程

2.1、注册流程时序图

2.2、多因素认证

2.3、自动跳转登录页面

三、涉及的技术与安全

3.1、用户许可授权

3.2、原生App权限

3.3、私域权限

3.4、加密与解密

3.5、前端相关的主要部分

3.6、后端相关的主要部分

3.7、安全相关的主要部分

一、登录流程

为统一多端的路由守卫的模式（App客户端、浏览器web客户端(含移动端)、webview客户端等），保证系统及应用的安全，本文旨在寻求一种通用的、标准化的方法，可参考大厂的做法，比如微信小程序-登录流程时序：

https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/login.html

1.1、登录流程时序图

说明：

⓪、可扩展为PaaS的后端服务：你的应用服务，可“剥离”为“业务API服务”和“平台API服务”，即上述“开发者服务”和“可扩展为PaaS的后端服务”。“平台API服务”，可以为第三方的“独立软件开发商ISV”提供接入服务，由它们代为“最终用户开发”，或扩展你的“业务API服务”的功能；同时，“平台API服务”，还可以作为“企业客户”的管理后端，统一管理为企业客制化的appid和appkey，每个企业都有一个唯一的“appid”标识。而且，“业务API服务”和“平台API服务”可以是“分布式架构”，它们之间，可以是1对1的关系、也可以是多对一的关系、还可以是”支持负载均衡“的多对多的关系。

①、“通用签名”和“一次性登录凭证code”：“通用签名”，可以被客制化为一个“可扩展为PaaS的后端服务”所提供的签名校验服务，它可以是一个同时具备“PreventDoubleSubmission防止双重提交功能”的时间戳的差值，这个差值极短比如0.03毫秒，即我们通常所说的“雪花算法ID”，可以有效防止一开始就被”ddos“攻击。“一次性登录凭证code”，相当于一个“一次性访问令牌”，下次再请求，该令牌就会失效。

②、AK换取SK：几乎是，所有大厂的平台服务，所采用的方式，即：拿“用户注册平台服务”时，所产生的AppID对象，“appid”及其键值"appkey"，携带临时令牌code，生成用户当前“会话”所使用的session_ID对象，“session_id”及其键值"session_key"。其中，session_key，会话密钥，是对用户数据进行加密签名的密钥。为了应用自身的数据安全，开发者服务器不应该把会话密钥下发到“多端应用”，也不应该对外提供这个密钥。

③、自定义登录态loginStatus：将session_key和openid按照客制化的特定算法进行关联，并存取到“开发服务器”持久化，可以存取到后端服务的数据库中，也可以持久化到开发服务器的redis键值对中，便于后期查询“签名密钥”进行“签名的验证”。

④、缓存自定义登录态loginStatus——Storage：将loginStatus缓存到“本地”，“本地”，对移动端App而言，即使其应用的“沙盒”路径下的loginStatus文件；对PC端的App而言，可以是操作系统的用户数据目录（比如MSWindows下的C:\Users\Administrator\AppData\Roaming\yourApp），也可以是该应用根下的某个专门存取的路径下的“加密”的loginStatus文件，读取时需要“解密”。对基于“浏览器或webview”的应用（比如html5网站、微信/支付宝/百度等的小程序），直接将其缓存到“Storage”下：