OAuth2.0和企业内部统一登录,token验证方式,OAuth2.0的 Authorization code grant 和 Implicit grant区别...

统一登录是个很多应用系统都要考虑的问题,多个项目的话最好前期进行统一设计,否则后面改造兼容很麻烦

  • cas认证的方式:新公司都是老项目,用的是cas认证的方式,比较重而且依赖较多,winform的项目也未集成进来,用户基础数据如组织机构权限等也未维护进来;其实就是cas登录后拿到usercode,然后去子系统映射相应usercode的用户的组织机构,权限信息, 缺点较多,暂不讨论;

  • token验证的方式:上家公司采用的方式,用的是基础数据平台统一登录(简称登录服务器),生成token,随url或者cookie带入服务端,服务端调用微服务去基础平台验证token有效性及获取用户信息;最近研究了下OAuth2.0 , 发现此方式是基本遵循 OAuth2.0 简化模式(Authorization Grant Implicit),还是比较好用;  流程大体如下(app1,app2是子系统):

  1. 用户登录app1,检查cookie和url有没有token信息;假设有,则通过基础平台api根据token获取用户信息;否则,转向登录url;
  2. 用户输入账号密码,登录服务器生成token返回返回原始url,回到第1步验证;
  3. 应用app1跳转到app2的时候,url带上token;app因为是内部系统,所以不做授权管理(比如qq的有应用管理),所有app共享一个token;
  4. token的保存,过期,重复登录等由登录服务器统一管理,采用内存服务器redis保证性能;redis key就是token,value是缓存用户信息,修改后需要重新登录才生效;
  5. 基础信息如组织机构,权限等,由登录服务器服务的页面维护,子系统只查询,不维护;子系统单据是否冗余组织机构名称等信息,还是只保存key,自由决定;
  6. 登录服务器所有表只逻辑删除,数据确保不会丢失;

再说说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直接跳转到权限不足页面即可)

 

转载于:https://www.cnblogs.com/binlin1987/p/8073960.html

你可能感兴趣的:(数据库,java)