鉴权中心系统设计

由于和钱相关的事件（借入、贷出、赚利差、转帐、扫码付款等）都需要前置校验，目前已有的鉴权方式有如下几项：

可能是以上一种或多种校验事件的组合，每个系统都要重复以上步骤，如：

由于这些前置校验的流程相对独立，和各个业务系统的耦合度不高，所以单独抽象出一个系统来统一处理这些鉴权流程，有如下收益：

[借出]为例流程说明

第一阶段：

1. 用户点击【借给TA】，App先调用业务Server系统；

1.1. Server判断这个操作事件需要做鉴权就调用AUC系统获取鉴权列表项，（如：肖像认证）；

1.2. AUC系统调用风控返，风控返回这个用户这个事件所需要的鉴权项列表，如：拒绝操作、上传资料审核、肖像认证、短信验证、无验证码、TouchID、免交易密码、登录密码，四要素鉴权（改成客户端）等；

1.3. 业务Server系统给端下发此次事件产生的orderID和从AUC系统得到的鉴权事件ID，下面以肖像认证为例；

第二阶段：

2. App直接和AUC系统进行交互，AUC再和后端的其他Service服务系统进行交互；

第三阶段：

3. 肖像认证成功后，App会调用业务系统（如：交易系统），把业务orderID传上去。

3.1. 业务系统携带orderID去AUC鉴权中心进行验证，如果鉴权中心返回认证/鉴权通过，则业务系统进行相关业务的后续操作，否则业务系统返回给端错误提示。

App/Server怎么知道哪些事件是需要走AUC鉴权中心？
原则：为了风控后续的规则统一，和钱有关的都要走鉴权中心，和用户保密信息相关的都要走。
建议：全业务流程走鉴权中心；App不需要知道哪些业务操作需要走，业务系统知道就好。
安全性
Server每次调用AUC系统生成的aucID是不同的，避免被重复使用的情况。同时APP要把事件的内容特征传给AUC，AUC和业务Server验证的时候也要匹配事件内容特征（比如，借出多少钱，哪个时间范围内操作的，用户信息，设备udid等风控需要的）。
App对多鉴权序列的状态维护
某个事件需要启用多少鉴权项，可以在AUC通过Server进行下发，AUC提供某个鉴权事件的后续鉴权流程查询。

失败场景说明：

步骤（1.1和1.4），调用AUC系统失败的情况下，或AUC内容调用风控等系统错误的情况下，业务系统Server拒绝提供服务；
步骤（2.1和2.5），2.1步调用失败的情况下，端要做相关提示让用户重新提交操作；2.5步AUC系统返回操作失败（鉴权失败、系统内部异常），端要提示用户重新提交操作；
步骤（3.1），端提交网络失败的情况下要重试提交操作；重复提交的情况下，Server要返回友好提示：正常进行中的提示语；Server根据业务场景做成同步等待结果或者异步间隔几秒查询的方式亦可；

新增接口，端和Server的鉴权流程走新接口完成；

现有的系统（交易、支付、收银台、悬赏）旧版本的客户端保留现有接口；

linkface原有的sync接口沿用，增加新的字段向前兼容；

尽量保持原有的数据格式定义，减少开发工作量和文档编写工作量；

接口文档（2015-12-18、19）
短信、交易密码、肖像认证、企业扫码、TouchID（开发：2015-12-21~26共5天，自测：26、27两天，联调待定：[关联系统：支付、交易、悬赏、收银台、企业版、风控]视各个系统改造时间）；
四要素、电话号码修改（开发：2016-01-04~09开发自测共7天，联调待定）；