用户中心导论

在互联网中，一切都是围绕用户来服务的，为了提供一系列服务，需要在服务中识别自然人个体，所以服务系统中出现了账号的概念来代表自然人，因为现在还不能把自然人通过某种方式直接在服务媒介上识别，所以互联网服务都是在用户想使用服务时引导用户注册一个账号的方式来创建账号。

如果不是一系列服务而是一个服务，其实可以让用户直接输入需要填写的信息一次提交进行服务，如：调查问卷
自然人与系统中的账号最好的一一对应关系

业务对象（领域对象）

账号要有唯一性，信息一部分是基本信息，另一部分是扩展的用户信息

唯一标识

账号在内必须有唯一性，而对用户他不需要非常明确的唯一，只要长久不变的唯一即可

对内的账号，会有uid或者userId的概念来代表唯一，不对外暴露
对外的账号会有account来标识唯一，每家公司最account的规则不一样
- 微信是用户自己设置的，如果不设置就是空
- 有的公司会要求必须有账户字段，如果不要求用户输入则自动生成一个账号唯一标识，如账号xxx
- account一旦设置不允许更改

基本信息

用户注册时的必须信息+个性化信息

系统账号信息：uid、account、类型、状态
个人账号信息：手机号、邮箱、昵称、头像、个性化信息
企业账号信息：企业邮箱、代理人手机号、企业图标

用户信息

用户信息是用户自己填写的信息

个人不变的自然人信息：姓名、身份证号、性别、生日、教育历史、工作历史、血型、籍贯
个人易变的信息：国籍、学历、当前工作、当前住址、婚姻、收入
企业信息：企业编码、企业名称、法人姓名、企业地址、企业logo

账号的分类

账号在多个系统中都有其存在，所以会有很多种类

对外
- 通行证个人账号
- 企业账号
对内
- 内部员工账号
- 外包人员账号

账号属性的区别

uid/userid 内部唯一id
account 用户所知的唯一标识
昵称用户对外的展示名称

业务行为（领域行为）

围绕账号有一系列服务，不过本质要解决的问题是认证、授权与会话。

认证

认证分为2个阶段，首先要创建一个账号，称作“注册”，要进行自然人与服务的映射认证绑定，然后使用这个账号完成认证叫做“登录”。

注册往往需要自然人的唯一性标识，注册认证成功后，用户就可以拿此账号进行登录完成登录认证

也可以每次都使用自然人的真实信息认证，在认证的第一次自动完成注册环节。
- 因为如果每次认证都使用真实信息会比较麻烦，要让用户输入过多信息，体验不好，所以采用第一种的比较多，比如一般账号都会设置一个密码，下次使用服务，只需要认证账户名+密码即可以完成。
- 不过现在由于手机验证码方式验证方便出现了登录也使用验证码进行登录的方式。
有的服务为了用户体验，注册完成时就自动登录成功了。
注册时认证最好的信息是自然人中最具有唯一性的标识，比如国内的身份证，国外的驾驶证护照之类信息。而这些信息往往比较长，而且过于隐私，对于用户来说心里门槛高，所以往往可以通过用户的手机号或者邮箱进行认证完成注册认证。
- 国内由于手机的普及倾向于使用手机号，而国外倾向于使用邮箱。
- 支付宝是强金融属性应用，使用身份证号进行注册
- 银行网银一般通过柜台认证的银行卡或者使用身份证号进行注册
- 手机号与邮箱都是可变更的，所以用这种方式容易导致用户注册多个账号的情况，为了避免可以在客户端记录上一次登录方式或者服务器记录设备信息对应的登录账号提醒用户
- 如果是注册or登录的流程，流程中可以在手机号验证后要注册新账号的时候提示用户是否注册或者要登录，这样登录后替换手机号码或者设置

认证中有个特别认证方式叫做第三方认证，本质是可信第三方授权+补充认证

如果第三方授权后第三方提供的信息足以满足本系统注册要求可直接生成账号并登录
如果不满足一般会在第一次三方授权后要求补充账号认证或账号信息后才能完成注册

业务形态

认证前
- 注册
- 登录
- 通过XXX找回密码
- 三方登录
- 完善账号信息
- 激活验证信息交互
认证后
- 修改登录信息
- 修改三方授权绑定
- 认证登录记录

授权

授权在认证之后，如果使用一项服务都需要先进行授权，同时使用一个授权服务往往还需要显示一份使用服务法律协议需用户同意

有些场景可以避免授权界面，比如使用一系列的服务时在注册或者登陆的协议中全部写入，即可免授权，不过这种在认证中绑定过多协议的做法可能是不合规的，尤其是金融行业，捆绑授权
比如工具服务中要使用一项P2P服务需要进行授权，支付宝中第一次使用花呗、借呗都需要单独授权同意后
还有一种对外授权，比如你的账号可以提供开放的能力，在其它平台中使用此账号可以登录认证并经过用户授权后把此账号的部分信息提供给第三方使用。

对内部账号的授权都是通过权限管理员分配的，所以与前台用户交互流程不一样

一般使用RBAC权限模型，即账号-角色-资源，把所有的CRUD操作设置为资源，然后一个角色包含多个资源，一个用户可以分配多个角色，角色相当于资源包的存在
超级管理员一般是不受权限限制的特例
资源的申请尽量自动化，所以一般使用工作流申请
有一种特殊的资源叫做菜单，从而菜单显示也通过权限来控制
资源的管理往往会增加应用这一级别用于隔离，为了同时操作多个资源每个应用会有资源包，而角色会作为跨资源包与资源的汇集方

业务形态

同意授权与协议
授权管理，协议查看

会话

会话是指用户从登录后用户持续使用服务一直到退出整个登录状态，与服务器中的session概念差不多，不过这里在登录后产生的

为了保持登录认证状态持续，最简单的做法是用户在输入用户名密码后将用户名密码保存在cookie中，以后每次请求都去校验cookie中的信息
但是这样非常不安全，所以一般在登录认证成功后会生成一个令牌，放到cookie中，每次请求都去校验令牌
为了防止令牌因为意外泄露后的风险，会给令牌设置一个有效期，客户端APP的有效期会更短，而通过刷新令牌机制来换取令牌保持会话持续

针对一些多应用或者跨域的情况会提供单点登录功能，即SSO

用户在同企业的一个平台认证后，则其他平台会自动认证成功
如果退出，也会全部退出

APP中的单点登录会有挤出登录的情况，会话类型会有多种

会话排他型：如果在同一个APP中，如果2个人用同样的账号在不同设备上登录，则前一个账号会被强制退出，一般针对金融类APP
会话共享型：同一个账号可以同时在不同设备上登录成功，一般用于工具类APP

业务形态

登录成功后生成会话
退出
自动登录
刷新令牌

业务行为附带信息

这种附带信息不止是用户中心，应该说对于所有业务行为都会有这些信息

通过设备请求获取的信息：设备唯一号、请求IP地址
通过来源APP请求的信息：平台号、版本号、投放标识
身份识别信息：用户令牌（认证前为空）

关注点

安全

安全分为通用技术安全与业务安全

通用技术安全

CSRF攻击
cookie安全
XSS攻击

业务安全：注册、登录、找回密码因为数据验证前操作，需要重点关注安全问题

短信验证码、邮箱验证码攻击安全
多业务步骤安全

账号集成

比如将2个公司账号系统进行整合集成打通的业务场景，这里暂不展开

自然人通过某种方式直接在服务媒介上识别YY：相当于一个第三方登录授权注册登录

PC通过信息传入识别
- ~~PC上比如指纹识别需要从硬件-操作系统-浏览器打通，非常麻烦，而且还要在设备上绑定好用户信息~~
- ~~PC人脸识别操作系统是支持了，不过需要浏览器可以调用，且需要电脑配备摄像头，也比较麻烦~~
PC通过信息传出识别
- ~~通过文字、声音不是太方便~~
- 通过图片可以，比如通过二维码图片，然后通过手机设备扫描然后通过认证
手机通过信息传入识别
- 指纹，如指纹支付已经有了，估计登录也可以注册的话需要本地设备设置个人信息需要手机软件支持
- 通过PC或者某个非手机设备生产的二维码这里用摄像头对准后识别注册or登录
- 手机的话通过APP唤醒其他第三方授权注册登录就是普通的三方登录
- 通过摄像头人脸识别可以有登录但是不能注册除非人脸库有你的信息
- 通过SIM卡信息或者网络基站获取本机手机号码进行注册，并通过手机号码获取实名信息