环境介绍，
一个大的系统由多个子系统组成。典型地，假设有一个平台，其上接入了多个应用。则有几个常见的问题需要处理，
1、SSO（包括单个应用退出时，需要处理为整个系统退出）；
2、平台跳转到应用、及应用间互相跳转时的身份验证；
3、应用调用平台接口时的身份/权限认证。
方案有很多，例如基于OAuth2的单点与接口授权，基于cas的认证等。下面简单说一下基于jwt和appkey、sercurtyKey的方案。
jwt，
1. 做一个ucenter模块，方便起见，该模块合并到平台工程中（复用一个库，这样读取用户信息更方便）
2. jwt由ucenter模块生成，在载荷部分包含了用户大多数信息，因此应用拿到jwt后，可以在自己的后台中创建用户（如果没有的话）。
3.jwt与应用+用户一一对应，可以记录在缓存中，由ucenter暴露出对外的方法，做得比较薄，目的是提高调用效率。
4. 用户登录时，不管是登录平台、还是应用，都需要到ucenter中进行认证，如果发现没有此用户，则导向登录页。登录成功后，ucenter生成载荷部分包含较全用户信息的jwt返回给应用，应用自行处理。典型的处理方式是应用用ucenter返回的用户信息在自己的后台创建用户，并做一次模拟登录。
5. 每个应用在登录、或自己的浏览器端传过来一个（对应用自己后端的）请求时，都会向ucenter请求身份认证（在缓存中查），如果没有，则导向登录页。
6. 有任意一个应用退出后，都会调用平台的退出接口，则平台将缓存中的jwt清掉，该用户的其它应用在做跳转、页面请求后台业务时，都会到ucenter验证身份 —— 在缓存中找对应的jwt，如果找不到，则认为已经退出/超时，导向登录页。
7. 注意，如果应用不与ucenter/平台部署在一起，则是需要远程调用的。
platformKey与sercurtyKey，
1. 接口调用授权：接口调用授权与jwt无关，平台的接口调用授权，是靠platformKey与sercurtyKey验证进行的。每次调用时，只要带上了这两个key，平台验证通过了，就认为是合法的调用。
2. 一个可扩展的点：可以在平台后端做哪些key对应开放哪些接口的控制。
一些具体案例，
一、两个系统对接，wlw应用，yz为平台。对接用户、机构、权限角色。
方案1. yz将所需的信息写入oracle数据库，wlw读取库。
方案2.
1）wlw初始化：yz提供批量获取用户信息的接口，wlw一次性获取，加入自己的系统，创建用户。管理员可批量设置用户的角色权限。
2）用户登录：用户在yz登录，跳转到wlw时，生成包含用户信息+机构的jwt串，传给wlw。
3）wlw检测用户是否存在，若不存在则创建。
4）wlw做一次模拟登录。
5）期间用户信息发生变化时（昵称、头像等），zy调用wlw的通知接口进行通知，wlw调用yz获取用户信息的接口进行更新。
权限角色：将yz的所有角色与wlw做一个映射，从zy同步到wlw的用户，按映射表赋予缺省的角色权限。如果有不满足的，在wlw后台人工修改。
二、三个系统， yk（Y）、zx（Z）、移动。 其中移动提供最基础的用户数据，外加一点机构信息。yk为平台，zx接入
讨论后，如下接入
Y Z
/
用户中心（ucenter）
|
移动
1. Z与移动合作开发ucenter。ucenter从移动获取用户基础数据，并
1）补充Y与Z需要的其它字段
2）维护组织机构（区域-学校-班级）
3）与移动进行用户信息的增删改同步。
2. Y与Z都分别与用户中心对接。
3. 场景：户登录Y/Z中的一个应用，称为A，并跳转到另一个应用B。
1）应用A到uCenter中进行认证，如果发现没有此用户，则导向ucenter的登录页。
登录成功后，ucenter生成包含用户信息（载荷部分）的jwt返回给应用A，A自行处理。例如用返回的用户信息在自己的后台创建用户（若用户不存在），并做一次模拟登录。若已经登录过则不做操作。
2）跳转到另一个应用B，B到ucenter中进行认证，步骤同上。
3）跳转到任何一个应用时，若是用户首次登录该应用，且此应用需要补全用户的信息，则首次登录时，弹出对话框让用户补全信息。
4）A与B互相调用对方接口时，调用参数中都需要包含用户id，服务提供方用id到ucenter中查看该用户的状态。根据不同的状态（登录/未登录等）+ 不同的接口 组合，按业务权限给出是否禁止调用等判断。
5）移动有数据变化时，通知ucenter，ucenter通知到Y与Z，Y与Z去ucenter中拉取数据。
6）Y与Z之一（A）退出时，通知ucenteer，ucenter刷新自己的状态。后续B跳转到A时，A到ucenter中检测到状态为未登录，会导向登录页，重复步骤1）