架构师小飞传第二弹 - 登录系统的设计

小飞，在完成纯数据型服务的同时，还要考虑服务的认证问题。通过调研小飞了解到原来HTTP的认证方式有这么多种，而最适合数据服务的接口访问授权模式是APIKEY模式，小飞的调研方向也是从这里开始的。小飞写了一个配置文件。其中包含了配置项APPKEY，是手动的。给每一个上游服务提供了一个唯一性的标识。

image

• 用户向业务系统发出资源请求

• 业务系统自己验证用户的登录信息

• 业务系统进行自己的统计

• 业务系统添加上自己的APPKEY

• 访问数据服务

• 数据服务读自己的配置文件。从而判断APPKEY是否合法

  这种模式简单容易实现，不过很快就遇到了问题。因为团队之间的某些关于人的问题，小飞团队希望能知道每个用户的访问情况。于是演变成了从用户通过AppKey访问平台，并由平台办法给用户APIKEY。用户每次根据APIKEY来访问接口。
  image

• 用户向业务系统发出请求

• 业务系统会根据自己的APPKEY以及用户的ID向服务系统发出申请APIKEY的请求

• 数据服务将生成的APIKEY写到Redis中，并记录一些必要的用户信息

• 数据服务将APIKEY通过业务系统直接返回到用户系统

• 用户获取到APIKEY

• 再次请求时，用户将APIKEY带到每个请求中

• 业务系统将APIKEY带到数据服务中发出请求

• 数据服务根据在Redis中找到APIKEY对应的信息

• 返回给用户数据

随着业务的发展，小飞也开始有了自己的第一个业务系统，有了自己的登录系统。但是小飞遇到了一个难题，用户数据被其他团队牢牢地攥在手里，经过多次的沟通都拿不到数据，其他端对只愿意给小飞提供登录接口，不肯提供用户数据给小飞。小飞做了一个奇葩的决定，其他团队的登录系统作为自己业务系统的下游。

image

• 用户输入Name和Password发送到认证系统
• 认证系统进行用户的获取
• 认证系统将用户信息封装成JWT返回给用户
• 用户访问业务系统
• 业务系统解码JWT
• 业务系统将解码的用户信息中APIKEY拿出来
• 业务系统访问数据服务的时候带上APIKEY
  HTTP协议是无状态的，也就是说，如果我们已经认证了一个用户，那么他下一次请求的时候，服务器不知道我是谁，我们必须再次认证。JSON Web Token (JWT)是一个开放标准(RFC 7519)，它定义了一种紧凑的、自包含的方式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。这里JWT的知识，还是可以去了解阮一峰老师的博客小飞的Web让公司看到了价值，兄弟团队要两个项目可以免登录相互跳转。这一下可费了劲了！在这时候小飞又学会一招，signature认证。

小飞之前的登录系统，前端居然是用明文传输的。这要是被中间拦截了，找谁说理去？小飞记得当年上学的时候配置SSH免密登录，还有Github的认证。

image

• 用户向认证服务请求私钥
• 认证系统通过x.509系统生成一对秘钥同时生成SSID记录到Redis中
• 用户获取到公钥之后对用户的密码和账号进行加密
• 用户用自己的SSID和密文，发给认证服务器
• 认证服务器通过x.509对秘钥进行解码获取到用户名和密码
• 认证服务器再通过用户名和密码进行用户的认证

小飞的团队越来越大，又来了两个产品经理。两个产品经理串通一气，要求实现单点登录的功能。于是乎小飞决定亲自上阵。在打通前后端的不归路上越走越远。

image

单点登录(SingleSignOn，SSO)，就是通过用户的一次性鉴别登录。当用户在身份认证服务器上登录一次以后，即可获得访问单点登录系统中其他关联系统和应用软件的权限，同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改的，这意味着在多个应用系统中，用户只需一次登录就可以访问所有相互信任的应用系统。这种方式减少了由登录产生的时间消耗，辅助了用户管理，是目前比较流行的总结，无论多么复杂的流程与机制，只要系统有一条流程线就不会混乱。

• 用户访问系统，如果没有权限会302到页面
• 用户在SSO页面完成登录
• SSO后端将JWT以及状态码返回给页面
• SSO前端将JWT，302回业务系统的前端
• 业务系统获取到302访问后端
• 业务后端向SSO发出请求，带上JWT
• SSO向业务系统返回UserInfo的JSON格式

认证

• Appkey和ApiKey的应用
• Cookie和Session的应用
• jwt和session

登录

• 原理
• 单点登录

用户中心

• 脱敏
• 中台
• RBAC