注意，这个文件必须以UTF-8无BOM格式编码。
一、用户登录模式
密码登录也分为三类： 一类是需要用户输入的文本型密码登录， 一类是手势绘图， 一类就是生物密码。
指纹也算是生物识别的，人脸中只是生物的一种，语音也算生物识别
先说密码登录，密码登录过程中的密码非常关键，这个是识别用户的前提，也就是说，只有密码通过验证了，系统才会认为，系统的当前使用者，才是系统中指定的模型记录，我们知道，系统最大的风险其实就是身份冒用，而这个登录，就是身份认证的第一道关。
前面我们说了几种登录认证方式，从安全角度上来说，安全性肯定不是一个级别的，比如生物识别的安全性肯定要高于其它方式的，所以，在登录场景下，系统往往需要提供一些风控变量，如IP，手机标识等，同时系统中会登记着用户的常用IP，常用终端等，这些环境变量都是系统后台处理的，用户基本上不会有感知的。不同的登录方式，需要搭配不同的风控因子。
二、主流程
我们先说一下主控流程，核心系统收到登录鉴权请求后，是怎么处理的。
- 肯定先要检查登录标识即账号，如手机号存不存在，如果不存在，需要返回异常码给业务系统。
- 如果账号存在，则进入验密阶段，如果验证成功，则找到此用户的系统模型，即用户ID, （USER_ID）。
- 作为核心系统，不只是说密码对了就行了，还要看这个用户本身是不是具有风险，要检查用户的各种状态，还有用户标签，比如用户状态是正常的还是冻结的？用的安全等级是多少？用户是不是被列入黑名单？用户身上被打了哪些标签。
问个问题，如果此时用户被冻结了，对于用户登录这个接口，核心系统应该返回成功还是异常？ 应该返回成功，并给出冻结标记，用户登录成功后，不论用户是什么状态，都要将用户基本信息、用户状态、用户标签等统一返回业务系统。这个用户状态的冻结，意味着用户接下任何业务都会受限。比如司法冻结。所以，这个接口要返回成功，及用户基本信息还有其它的信息。
这里有个规定，业务系统收到返回值， 要坚决执行字段语义，比如，业务系统收到 用户密码需要强制修改的语义，业务系统就应该引导用户去修改密码界面。还有，如果用户被冻结，系统也要根据业务规则给用户提示拒绝用户使用系统，特别是用户标签，语义特别多，业务系统根据不同语义做不同的逻辑处理。虽然核心系统不参与业务，不干预业务，但却维护着最基本的业务底线，这是所有业务系统达成的契约，都要共同遵守的。比如，用户已经被冻结，即使业务系统让用户使用系统，但是当用户进行支付的时候，要进行支付密码的签权，此时的支付密码鉴权就会直接抛出异常，而不管用户的支付密码是否正确，系统在返回结果的同时（不论成功还是失败），都要异步的去登记日志，并将事件记入关键事件表。
三、防止暴力破解
检查密码失败次数，原理上是的，核心系统只允许用户在规定的时间内进行一定的次数，如果超过这个限制，就会将密码保护起来，在保护期内，不论用户上送什么密码，直接拒绝处理。所以，在验密的时候，有个错误次数检查和密码是否处于保护状态的一个逻辑处理。由于这种保护只是临时性的，有时限的，所以，过期后要系统自动去保护。 对于登录密码撞库这块，由于是后台处理，我们在支付密码的时候，再讨论
四、其他
大家先消化消化，业务系统这块我没讲，比如用户在登录的时候，业务系统要请求风控系统，对用户当前所处的环境进行一个风险评级，再根据不同的风险评级要求用户上送不同的条件，如是否要外加手机验证码，是否要求用户输入图形码等。这块不属于核心系统的。 登录其实算是最简单的功能了，但是里面还有不少细节需要考虑，大家可以多发挥发挥，我只是抛块砖出来，大家其实也看出来了，每个业务里面都有风控的处理环节。
五、问题
Q1：我插一句 不管何种登录方式登录来源(密码/微信手势手机生物指纹等等) 最终要对应到我们系统的用户 然后生成session 然后分发session 然后完成。业务系统如何获得当前用户的信息 只能通过session反查吧 session可以多级别(可以依赖产生吧)
A1:对于我们的核心系统来说，不关心session,会话由业务系统去保证,因为核心系统是无状态的。刚才说的登录原理是对的，不论哪种登录方式，都是为了验证用户身份，同时找到该用户。 A12：回到你刚才那个问题，用户登录成功后，核心系统会直接把用户信息返回给业务系统，比如用户ID，你说的session是业务系统处理的范畴了，核心系统并不关心。业务系统一般会采用分布式缓存或共享Session的方式，将用户信息进行缓存起来
Q2：我建议在每个业务里面保留风控的钩子，然后做统一的风控模块来接入。风控独立出来整体设计，可能会清晰点。 A2：在设计文档的时候，可以体现出来
六、短信下发
短信下发，是指业务系统的短信下发，可以调用基础设施短信网关，短信网关可以做一些通道备份等。
在短信下发接口里，有着两层业务：
- 短信模版
一般下发短信，都是通过短信模版来实现，不同的业务调用不同编号的短信模版来下发短信。 系统里都会维护一系列的短信模版，并通过占位符约定一些变量，如$｛RDM｝表示随机码，${PRE_MSG}表示在模版前面附加一段文字等
- 验证码的生成
业务系统验证码验证的时候，必须上送调用下发短信时返回的token。如果不用token,系统只能识别到最后一次短信下发的验证码，而且区分不了业务场景。假设在支付场景需要短信验证码，黑客可以欺骗用户在其它环节获取到验证码，从而实现资金盗窃。
除此之外，由于短信下发是需要收费的，所以都会有流量保护：业务系统会有图形验证码来确认是人工操作，同时，核心系统也应该要有发送频率、发送总量的风险控制。
一般情况下，企业都会先建一个基础的短信调用平台，提供基础的调用能力，核心系统通过基础平台实现短信功能
有两个问题大家思考一下，看怎么处理：
Q1. 短信重发，并且需要与上次的验证码内容一致，该如何处理?
A1：短信重发是核心系统的一个接口，短信重发接口需要传递 token，接口业务发现该token存在有效期内的验证短信，就不重新生成，直接重发验证短信。 A12：验证码在有效期内是可以再次重发的，重发后，有效期自动延长，但重发次数不能超过三次。
Q2. 如何避免验证码的多次验证?
A2：验证码前期存在库里就可以了，验证码一般验证完成后，要标注此条失效，验证完的失效，超时的也失效。失效验证码记录，可以移到历史表中。
Q3. 这个时间是验证码的有效时间，验证码的有效时间一般设置多久?
A3. 一般不会超过5分钟。当然，也可以在短信模版中设定好, 做成可配的。
另外，这里容易犯一个错误：将业务系统当成工具系统，因为客户系统具有短信验证码下发功能，很多业务系统都会没有原则的调用此接口，不管这个业务和客户业务有没有关系。为了解决这个问题，客户系统不对外提供短信验证码验证功能，所有验证都和具体业务绑定在一起。