3. 账号系统

1. 功能模块

账号系统分为三大功能模块和一个相关业务模块：

a. 登入模块: 承载各类场景的各种方式的注册和登入的功能；

b. 管理模块: 包含会话管理、绑定解绑和基础信息修改等功能；

c. 安全模块: 具备实人实名、人机交互和风险防控等功能；

d. 业务模块: 与会员、权益域紧密结合和拓展, 帮助业务增长；

2. 典型流程

下面简单介绍典型的两类登入流程：

2.1. 单点登入

2.1.1. 登入由来 

a. HTTP 无状态: 由于 HTTP 的无状态特性, 导致用户登入后的每次后端访问交互, 上下没有任何联系。所以服务端无法对端的每次独立请求, 进行用户有状态的上下文校验；

b. 基于会话机制: 如果想实现有状态的登入, 需要浏览器或端在应用层来存储登入的状态, 并具备资源保护机制: 保护本域的资源, 过滤非本域的资源。此时引入了会话机制：浏览器第一次访问, 服务端生成会话对象并返回会话标识给端和缓存；当浏览器第二次或三次访问时, 通过携带本域的会话标识参数, 服务端据此判断会话的合法性和有效性。浏览器上传会话标识时, 通常有两种方法 ①. 通过 Cookie 携带 ②. 通过请求参数, 当浏览器关闭 Cookie 功能时。

另外每款的 APP 应用, 对于用户需要保障一致性的用户体验, 但在后端通常划分为很多垂直域的子系统, 且每个子系统访问都需要用户登入和准入。如果每个子系统的访问都需要用户的账密登入，此时会严重影响子系统之间的用户交互体验, 同时也暴露了更多的账号安全风险。在这需求背景下同时结合会话机制的技术, 产生了单点登入(SSO)：即在多个应用系统中, 用户仅需要登入一次, 即可访问其它相互信任的子系统。

2.1.2. 登入方式 

单点登入通常两种方式: 共享 Cookie 和 CAS 登入；

a. 共享 Cookie：早期不同子系统域名根路径一致, 在浏览器侧可以通过共享顶级域名的 Cookie, 来访问不同子系统的子域名。这种方式有明显的缺点： ①不同地址需要继承相同的顶级域名；②后端不同子系统需要共享相同各自的 Session。

b. CAS 登入: 表示一次登入, 到处使用的思路；

单点登入网上经典的流程如下, 其关键点：

a. CAS 服务：独立的 CAS 登入系统，负责所有子系统的账密登入和票据颁发; 

b. 票据 ST：各个应用系统后端：端首次访问时会根据端上传的票据 ST 反向去 CAS 系统校验登入的合法性；

c. 应用系统：各个独立应用子系统登入成功后, 会基于会话机制进行前后端的交互；

2.2. 三方登入

2.2.1. 三方登入

三方登入在 APP 和页面端已经普及应用, 其好处主要有: 

a. 降低流失：快捷用户登入和降低登入流失率，对于用户可以直接借助高 DAU 的 APP 如微信、支付宝等直接进行登入, 减少用户新注册 APP 的成本；

b. 减少设计：快捷获取用户信息和减少产品登入设计， 可以简化用户系统的注册机制, 节省用户系统设计和实现成本；

c. 提高转化：利用三方应用的用户关系, 提升用户互动率和转化率；

2.2.2. 登入流程

Oauth 认证的类型有好多种，流程总体分为下面四步：

a. 获取授权码 Code：跳转三方应用登入页面, 用户输入账密登入成功后, 返回给端的授权码, 通常会有短暂有效期；

b. 获取访问令牌 AccessToken：通过授权码去三方应用获取访问令牌, 及其有效期和具备的访问权限；

c. 获取用户 OpenId：通过访问令牌拿到三方应用的开放身份标识；在有些应用 OA 流程，OpenId 直接在第二步和访问令牌直接返回；

d. 获取用户授权信息：通过 OpenId 获取授权的用户基础信息, 例如用户昵称和头像等。

2.3. 实人验证

实人认证是账号行为的风控常见手段之一,  常触发于游戏、电商和金融等认为高危的行为场景。例如账号关键信息变更、冒充账号、额度交易等。实名是实人认证的前提, 实人认证可以借助三方权威 SDK 来实现, 流程如下：

3. 账号安全

账号安全始终是账号系统重要而难防的课题。常见的账号安全分类: 

通常由的防御手段如下：