Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
200 lines (128 sloc) 11.5 KB

个人认知

  • 在稍微大一点点的公司中,有两个基础系统是必然有的:一个是:SSO(单点登录系统),一个是 UPMS(通用用户权限管理系统)
  • 而这两个系统都是很难完全地直接套用开源框架。因为,在这类规模公司中,基本已经有成气候的系统、用户,这部分用户体系,不可能说换就换。一般是要反过来设置:让新系统去适应现有的账号系统、权限管理体系。
  • 目前单点登录技术选型中,用得比较多的有:CAS、Keycloak、Spring Security OAuth2
  • 其中 Keycloak 除了认证还带各种授权玩法,整个体系的规划挺好的,适合业务的一开始阶段。如果是成规模之后再考虑要使用它,改造成本很大。
  • CAS 什么都好,支持了各种扩展接口,几百个可扩展的子模块。但是,这么大的项目现在就一个人维护,他既要开发又要写文档、写测试,实在是难为他了。记忆深刻 2017 年他嫌提问的人太 low、太麻烦,直接把 issues 关了,至今未开。而且这家伙非常喜欢用新版本,JDK、Spring Boot 动不动就升级。现在想起研究它的那段时间,简直了...Orz
  • Spring Security OAuth2 是 Spring Cloud 流行之后大家非常喜欢用的一个系统。目前来说真的没啥缺点,不管是可读性、可维护性、可变更性等方面上,大家都很喜欢。但是,不够灵活,业务上的灵活,特别是国内各种非工程化思维下的各种特殊要求。我不觉得老板们这些需求不合理,但是基于这些开源系统真的好难。
  • 所以,我写了 TKey,目标很明确:需求总是各种各样,我没办法帮大家做好扩展,那我就帮大家写好文档。你们自己知道怎么用,自己爱怎么改就怎么改。

OAuth 核心(比较绕)

  • TKey 的接口是按照 OAuth 2.0 规范来,所以必须了解这个。
  • OAuth 2.0 是规范、是安全标准,不是框架。它的核心逻辑是:颁发 Token,使用 Token
  • OAuth 2.0 规范定义了授权协议,不是身份认证协议
  • OAuth 2.0 广泛用于各大开放平台,比如大家常接触的 QQ、微信等平台
  • 认证系统可以支持很多协议,比如 SAML、LDAP 等,OAuth 2.0 可以只是其中的一种。
  • 单单的 OAuth 2.0 协议是做不了一个认证系统
    • OpenID Connect 开放协议是建立在 OAuth 2.0 之上的,它就可以作为认证协议
    • 除了 OpenID Connect,基于 OAuth 2.0 构建的协议还有很多,UMA、HEART、iGov 等
  • TKey 作为认证系统的认证核心是:
    • 用户持有的 TGC 令牌(ID 令牌),它才是代表着用户信息,代表着认证系统的登录证明。用户与登录系统之间是用 TGC 来连接。TGC 生成方法:oauthGenerateService.generateTgc();
    • OAuth 所颁发的 Token 是让客户端系统(业务系统)与认证系统之间进行连接
    • TKey 基于 OAuth 2.0 进行设计的的最大好处在于它是通用标准,在让别人来对接我们登录系统的时候只要按照标准即可
    • 所以,可以把接入 TKey 过程理解成接入 QQ 开放平台、微信开放平台过程
  • 授权码模式时序图

授权码模式时序图


常见登录系统

  • 最优秀登录系统:Google Accounts
  • 较一般的:腾讯、阿里等
    • 阿里的淘宝和天猫是同一个用户体系,阿里云是另外一个体系。
    • 腾讯的 QQ 和微信各自独立
    • 百度普通用户和百度智能云用户也是两个用户体系
  • 类似 Okta 这类新玩法,当前国内 saas 丰富度还不够,暂时比较艰难

登录系统的几种场景

  • 最核心的点: 对于业务系统来讲,有没有前置的 API 网关影响一生
  • API 网关作用: 路由、过滤、身份验证、鉴权、限流、熔断、重试、监控、负载、版本/灰度发布、缓存等等
  • API 网关是所有请求的第一道入口,如果你们公司刚好再做整体系统架构调整,要引入单点登录系统之前,我建议一同连同 API 网关一起调研了

开放平台的登录系统

  • 类似 QQ 第三方登录过程
    • 你需要找 QQ 开放平台先申请 AppId + AppKey
    • 也有人叫做:AppKey + AppSecret; ClientId + ClientSecret
    • OAuth 2.0 规范的标准叫法是:ClientId + ClientSecret,具体点击查看
  • 采用授权码模式拿到 QQ 平台给你的 AccessToken
  • 这个 AccessToken 你只能获取到用户基本信息
  • 在你调用 QQ 平台的所有接口过程中,必须带上该 AccessToken,不然它不知道是谁在调用
  • 你只能跟 QQ 开放平台打交道,你不能拿着这个 AccessToken 去调用微信开放平台

有 API 网关的同构业务系统

  • 比如 Spring 的 Spring Cloud 体系
  • 对身份进行认证全部交给 Gateway、Zuul,内部的业务系统只要管理好自己的 API 服务即可
  • 在 Spring Cloud 体系中,内部的服务都是在内网中,都是设定彼此之间是安全的

有 API 网关的异构业务系统

  • 有的公司有好几个研发中心、研发部门,各自采用各自的业务系统架构(历史原因)
  • 引入 Kong、Tyk、OpenResty + Lua 等 API 网关之后,各个业务系统在网关后面,身份验证也是交给网关

无 API 网关的同构 / 异构系统

  • 这种场景在中型公司转型过程中基本都要遇到,我个人建议是 API 网关和单点登录一起抓
  • 这里说下在有单点登录系统情况下,但没有 API 网关的跨系统调用
    • 业务系统 A 在单点登录系统登录成功后拿到属于自己的 Token-A
    • 当同一个浏览器访问业务系统 B 的时候,B 系统也是需要登录的,但是因为单点登录系统已经知道当前浏览器是谁在用,所以直接给业务系统 B 颁发了 Token-B。这个过程用户无需重新登录,也就单点登录了
    • 业务系统 A 自己维 Session-A 与 Token-A 之间的关系
    • 业务系统 B 自己维 Session-B 与 Token-B 之间的关系
    • 这时候业务系统 A 要调用业务系统 B,必须拿着 Token-A 去找业务系统 B
    • 业务系统 B 拿到请求中的 Token-A 会找单点系统询问该 Token-A 是否有效,以及 Token-A 对应用户信息是谁
    • 业务系统 B 知道当前请求是谁之后就会放开请求
  • 这个过程是一个瓶颈
    • 如果业务系统 B 自己不存储这些 Token-A,则每次都要询问单点登录系统,单点登录系统压力会很大
    • 如果业务系统 B 自己存储这些 Token-A,则 Token-A 的时效性就有偏差

OAuth 2.0 与 JWT

  • 现在有很多人喜欢用 Spring Security OAuth + JWT 构建登录系统
  • JWT 的自包含、防篡改的特点让很多人喜欢,可以省掉最让人烦的集中式的令牌,实现无状态。
  • 可是,这是有场景限制的。比如主动吊销 Token 要如何处理、有效时长如何动态控制、密钥如何动态切换。
  • 如果没有主动吊销 Token 的业务需求,那自包含的特点确实很有用,只是看大家的业务场景了。

其他核心术语认知(提供了查询入口)

架构设计 无状态

认证 与 授权 的区别

HTTP 请求头:User-Agent

HTTP 状态码:301 302 401 403

跨域

分布式 无状态

中间人攻击

重放攻击

Session 与 Cookie

Tomcat JSESSIONID 作用

Cookie HttpOnly secure

LocalStorage 与 SessionStorage

Basic Auth Bearer Token

OAuth 2.0 四种授权模式

  • Google 搜索
  • Baidu 搜索
  • 授权码模式把步骤拆开,最核心的点:保证了是客户端本身进行的身份认证。简化模式就做不到,所以不推荐简化模式。

OAuth 2.0 state CSRF

OAuth 2.0 redirect_uri 验证

API 网关的作用

UPMS 用户权限管理系统

You can’t perform that action at this time.