微服务认证解决方案

之前整理的微服务认证文档,分享一下

微服务认证解决方案

    • 1.Token认证有两种方式:OAuth2.0,JWT
    • 2. oAuth2.0授权方式
      • 2.1授权码模式:
      • 2.2简化模式:
        • 简化模式详细介绍
      • 2.3密码模式:
        • 密码模式详细介绍
      • 2.4客户端模式:
      • 2.5结论:选择密码模式
    • 3.依据用户名和密码,获取token验证,访问资源服务器流程
    • 4 .名词解释

微服务认证有四种解决方案,分别是:单点登录SSO方案、分布式会话(Session)方案、客户端令牌(Token)方案,客户端和API网关结合;

  • 单点登录方案:是最常见的解决方案,但是每个与用户交互的服务,都需要通过认证服务器通信,会产生大量的重复认证,和网络碎片流量。
  • 分布式会话方案 :将用户信息session 共享存储;当用户访问微服务时,直接从共享存储中获取。该解决方案在高可用和扩展方面很好,但是会话信息保存到共享存储中,要保证数据安全这块,实现复杂度比较高。
  • 客户端网络令牌方案:令牌有客户端生成,并由认证服务器签名,在令牌中包含足够的信息,客户端在请求时会将令牌附件在请求上,从而为为各个微服务提供用户身份认证。但是如何及时的注销用户认证则是一个大问题。
  • 客户端令牌和API网关结合 :通过微服务架构中实施API网关,将原始的客户端令牌转化为内部的令牌,一方面可以有效的隐藏服务,另一方面通过API网关的通一入口可以实现令牌的注销处理。
  • 综上所述,采用客户端令牌和API网关,解决了会话信息的安全和及时注销用户认证问题。

基于令牌(token)包含几层含义:

  • 令牌是认证用户信息的集合。
  • 令牌包含了足够的信息,验证令牌就可以完成用户的身份的验证。
  • 服务器会通过HTTP头部中的Authorization获取令牌信息并进行检查,并不需要在服务端存储任何信息。
  • 通过服务端验证令牌检查机制,可以应用在浏览器,和其他第三方应用程序上。
  • 支持夸程序的调用。Cookie是不支持跨域访问,而token不存在这个问题。

1.Token认证有两种方式:OAuth2.0,JWT

OAuth2.0 授权流程
1)用户打开客户端后,客户端要求用户给预授权
2)用户同意给予客户端授权
3)客户端使用上一步的授权,向认证服务器申请令牌
4)认证服务器对客户端进行认证,确定无误后同意发放令牌
5)客户端使用令牌,向资源服务服务器申请资源
6)资源服务器确认无误后,同意向客户端开发资源

微服务认证解决方案_第1张图片

2. oAuth2.0授权方式

客户端必须得到用户的授权(authorization grant),才能获得令牌(access token)。oAuth 2.0 定义了四种授权方式。

  • implicit:简化模式,不推荐使用
  • authorization code:授权码模式
  • resource owner password credentials:密码模式
  • client credentials:客户端模式

2.1授权码模式:

1.用户访问客户端(应用界面);
2.客户端将用户引导到授权服务器上
3.用户是否同意客户端授权;
4.如果同意授权,授权服务器将重定到客户端事先指定的地址,同时附加上授权码(token)
5.客户端收到授权码后,同时附加上要访问的页面,经客户端后台服务向授权服务器申请令牌;
6.授权服务验证授权码后,向客户端发送访问令牌(Access Token)和更新令牌(Refresh Token)并重新制定上步指定的地址;

微服务认证解决方案_第2张图片

2.2简化模式:

指不通过客户端的后台服务器来获取访问令牌,客户端一般指的是浏览器,客户端通过脚本语言(一般是javascript)来完成授权服务器申请服务器的操作;

简化模式详细介绍

简化模式适应于纯静态页面;所谓的纯静态界面应用,也就是应用没有在服务器代码执行的权限,(通常把代码托管在别人服务器上),只有js代码的控制权限。
这种场景下,应用没有持久化的能力。因此按照oAuth2.0的规定,这种应用拿不到Refresh Token的。其授权流程入下图 。

微服务认证解决方案_第3张图片

2.3密码模式:

密码模式是指客户端通过用户提供的用户名和密码信息,直接通过授权信息服务器来获取授权。这种模式下,用户把自己用户名和密码提供给客户端,但是客户端不保存这些信息。
该模式使用,客户端高度信任的情况下。

该模式授权流程:
1.用户向客户提供相应的用户名和密码
2.客户端依据用户提供的用户名和密码,向授权服务器请求令牌
3.授权服务确认后,返回 令牌给客户端

密码模式详细介绍

密码模式中,用户向客户端提供自己的用户名和密码。客户端使用这些信息,向“服务提供商”索要授权(即:向授权服务器索要服务请求令牌)。在这种模式下,用户必须把用户名和密码给客户端,但是客户端不存储密码。这通常在用户端对客户端高度信任的情况下,比如客户端是操作系统的一部分。

一个典型的例子,同一个企业的不同产品要使用本企业的oAuth2.0体系。有些情况下产品希望能够定制化,授权界面。由于同一个企业,不需要授权通过授权界面来,询问用户授权意向,而只需要认证用户身份即可。这个时候产品研发定制授权界面,用户输入用户名和密码,并直接传递给授权进行授权即可。

微服务认证解决方案_第4张图片

2.4客户端模式:

指客户端以自己的名义而不是用户的名义,向授权服务器进行认证;
客户端模式详细介绍
如果信任关系再进一步,或者调用者是一个后端的模块,没有用户界面的时候,可以使用客户端模式。鉴权服务器直接对客户端进行身份验证,验证通过后,返回 token。

微服务认证解决方案_第5张图片

2.5结论:选择密码模式

由于,简化模式整体过程,整个过程在前端界面实现,这里不建议使用,authorization code,虽然是最安全的,最严密的,但是网络交互比较多,由于cem项目是内网实现,相应的API开发的接口不会放在外网,因此建议在密码模式和客户端模式中,二者选择其中一个,建议选择,密码模式;
由于cem产品基本上部署打内网环境,建议选择密码模式,鉴权服务器直接对客户端用户输入的,用户名和密码,进行身份验证,换取token。

总结 依据产品实际情况出发,选择适合当前场景的 认证方式;

3.依据用户名和密码,获取token验证,访问资源服务器流程

后续补充

4 .名词解释

名词解释

  • 第三方应用程序(Third-party application): 又称之为客户端(client),比如上节中提到的设备(PC、Android、iPhone、TV、Watch),我们会在这些设备中安装我们自己研发的 APP。又比如我们的产品想要使用 QQ、微信等第三方登录。对我们的产品来说,QQ、微信登录是第三方登录系统。我们又需要第三方登录系统的资源(头像、昵称等)。对于 QQ、微信等系统我们又是第三方应用程序。
  • HTTP 服务提供商(HTTP service): 我们的云笔记产品以及 QQ、微信等都可以称之为“服务提供商”。
  • 资源所有者(Resource Owner): 又称之为用户(user)。
  • 用户代理(User Agent): 比如浏览器,代替用户去访问这些资源。
  • 认证服务器(Authorization server): 即服务提供商专门用来处理认证的服务器,简单点说就是登录功能(验证用户的账号密码是否正确以及分配相应的权限)
  • 资源服务器(Resource server): 即服务提供商存放用户生成的资源的服务器。它与认证服务器,可以是同一台服务器,也可以是不同的服务器。简单点说就是资源的访问入口,比如上节中提到的“云笔记服务”和“云相册服务”都可以称之为资源服务器。

你可能感兴趣的:(微服务)