跨平台跨端的登录流程及其安全设计
跨平台跨端的登录流程及其安全设计
目录
跨平台跨端的登录流程及其安全设计
一、登录流程
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”下：
1.2、三方App 登录
若你的服务，是PaaS的扩展平台服务，在你的App的基础之上，为第三方开发者提供API接入服务，可在上述流程开始，增设1个OAuth2.0的流程；首先征得”用户的同意“，三方服务，才可生效。
1.3、请求的路由守卫
对基于浏览器（含嵌入式浏览器）的客户端应用而言，一切，皆请求和响应，无论多页应用还是单页应用，均需要守卫上述1.1中的”自定义登录态“，任何对目标服务的请求，没有自定义登录态或自定义登录态失效，均需”重新进行登录“。
对原生App（含多端）而言，也同样遵循“路由守卫”法则。
二、注册流程
2.1、注册流程时序图
如上，关键是要对标“1.1、登录流程中的②、AK换取SK”。
2.2、多因素认证
OAuth2.0第三方认证，可以是权威大厂的手机验证码、可以是公众广泛认同的第三方“互联登录”（比如“微信登录”、“QQ登录”、“支付宝登录”、“百度登录”等），也可以是它们之间的组合。
对于“企业级”应用及“平台级”的应用，可能还会涉及“用户工商信息”的提交流程与审核流程（本案，略）。
认证的目的：验证，请求者，是人，而非“机器”代码。
2.3、自动跳转登录页面
进入“登录流程”。
三、涉及的技术与安全
3.1、用户许可授权
本案，整个生命周期，都应严格按照中国“公安三所等保认证”的要求进行设计、架构和实施，以免后续不停返工。
应当按照工信部要求， 凡是涉及用户隐私的环节，都主动出示“用户隐私保护协议”，并拉起“用户授权”的平台界面，供用户阅读与授权同意，无论html前端涉及的Cookies，还是移动App涉及的用户设备能力及其三方sdk引用，抑或是微信等私域应用所涉及的用户隐私，均需征得用户授权。
3.2、原生App权限
▪ Android客户端平台：AndroidManifest.xml及其相关权限代码
▪ Ios及MacOS客户端平台：info.plist.xml及其相关权限代码
▪ MSWindows客户端平台：UAC及ACL相关的权限代码
3.3、私域权限
▪ 涉及微信小程序等应用内的权限请求
▪ 涉及支付包小程序等应用内的权限请求
▪ 涉及百度小程序等应用内的权限请求
3.4、加密与解密
▪ 对称加密AES
▪ 非对称加密RSA
▪ 国密：OpenSSL与SM2、SM4
3.5、前端相关的主要部分
▪ 网络三剑客：Html5 + Css3 + ES5/ES6（及其TypeScript）
▪ Web APIs、
▪ HTTP协议
▪ 其它主要的web开发技术
▪ 工程化与模块化：webpack(3/5后)、vite、Node.js相关部分
▪ 主要的三方框架：Vue(2/3)、React(新React)、Node.js相关部分
3.6、后端相关的主要部分
▪ Node.js（express）和Egg
▪ 编译型开发工具及其语言：C和C++、 Delphi；Java等
▪ 数据库：MySql、MS Sql Server、Oracle等；IndexedDB、Redis
3.7、安全相关的主要部分
▪ 网络协议和操作系统的安全
▪ ddos分布式拒绝服务攻击-Distributed Denial of Service
▪ 其它（太多太细，略）
▪ web安全-最常涉及的内容
▪ 同源策略与cors跨域资源共享
▪ CSP跨域安全策略
▪ 缓存相关的安全：强制缓存与协商缓存；Cache Storage、Session Storage、Cookies、Loacal Storage
▪ Worker专用线程、Service Worker服务线程，及其安全
▪ SSL、TLS及Https
▪ JWT（Json Web Token）
▪ OAuth2.0标准
▪ CSRF跨站请求伪造攻击与反攻击-Cross-site request forgery
利用站点对用户的信任骗取user info
▪ XSS跨站脚本攻击与反攻击-Cross Site Scripting
利用用户对站点的信任骗取user info
▪ 登录和认证-服务端（以上的技术融合，做好它是一切的前提）
▪ 登录和认证-客户端（以上的技术融合，做好它是一切的前提）
▪ 整理与归纳-涉及浏览器相关的安全领域
▪ 整理与归纳-涉及原生App相关的安全领域
▪ 整理与归纳-涉及私域应用相关的安全领域
喜欢的，就收藏并点个赞，鼓励我继续技术的原创写作及经验分享：
《大厂后台管理passportal鉴权登录的通行做法-之腾讯云研究》
需要改进的过往组件：《App账号注册登录设计》