统一登录是个很多应用系统都要考虑的问题，多个项目的话最好前期进行统一设计，否则后面改造兼容很麻烦；
-
cas认证的方式：新公司都是老项目，用的是cas认证的方式，比较重而且依赖较多，winform的项目也未集成进来，用户基础数据如组织机构权限等也未维护进来；其实就是cas登录后拿到usercode，然后去子系统映射相应usercode的用户的组织机构，权限信息， 缺点较多，暂不讨论；
-
token验证的方式：上家公司采用的方式，用的是基础数据平台统一登录（简称登录服务器），生成token，随url或者cookie带入服务端，服务端调用微服务去基础平台验证token有效性及获取用户信息；最近研究了下OAuth2.0 , 发现此方式是基本遵循 OAuth2.0 简化模式（Authorization Grant Implicit），还是比较好用； 流程大体如下（app1,app2是子系统）：
- 用户登录app1，检查cookie和url有没有token信息；假设有，则通过基础平台api根据token获取用户信息；否则，转向登录url；
- 用户输入账号密码，登录服务器生成token返回返回原始url，回到第1步验证；
- 应用app1跳转到app2的时候，url带上token；app因为是内部系统，所以不做授权管理(比如qq的有应用管理)，所有app共享一个token；
- token的保存，过期，重复登录等由登录服务器统一管理，采用内存服务器redis保证性能；redis key就是token，value是缓存用户信息，修改后需要重新登录才生效；
- 基础信息如组织机构，权限等，由登录服务器服务的页面维护，子系统只查询，不维护；子系统单据是否冗余组织机构名称等信息，还是只保存key，自由决定；
- 登录服务器所有表只逻辑删除，数据确保不会丢失；
再说说OAuth2.0, 比如qq，微信，微博等的OAuth平台，基本是基于OAuth2.0 Authorization code grant模式，先获取code，再获取auth token;
OAuth2.0 grant有四种模式，网上介绍也很多，简单说下：
- Authorization code 授权码模式：授权后先获取授权码code，再根据code获取token，注意code是不对客户端开放的，服务端app1可以通过code任意时间refresh token；各大互联通平台基本都是通过此模式写的开放登录平台及api实现；
- Implicit grant 简化模式： 这个是相对授权码模式的简化；简单说少了一步获取授权码code的步骤；直接返回token，RFC6749的解释是：直接暴漏给客户端token，可以由客户端JS等完成，无需通过app转接，有一定的风险性；（个人认为主要就是不能通过授权码定时刷新token，安全性低）；
- Resource Owner Password Credential 用户名密码模式： grant_type=password，直接给app保存用户名密码，当然就可以访问了，当然安全性最低，密码多出保存，泄露就一锅端；
- Client Credential 客户端模式： grant_type=client_credential， app1和登录服务器相互信任，客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。（没深研究，个人认为这已经超脱OAuth需要处理的范畴）
细看一下，“token验证的方式“就是OAuth2.0的Implicit grant 简化模式，只不过更精简：多个子系统app公用一个token，token不绑定app；子系统间的跳转完全依赖token的传递；权限统一在登录平台申请和管理（可以根据app管理），各个app只负责通过api获取和权限验证，更试用于企业内部系统；（比如一个权限名为“app1的登录权限”，假设api返回的权限list没有此权限，则app1直接跳转到权限不足页面即可）