（第一篇）微服务架构下无状态权限认证系统设计（Spring Security + Oauth2 + JWT）

本文主要就采用Spring Security + Oauth2 + JWT的技术实现在微服务框架下的权限控制做一个总结及分享。

一、选型阶段

       1.主要权限框架趋于在shiro 与 Spring Security之间做选择，shiro以前做的集成项目有用过，也跟当时的开发工程师了解过，特点是简单，扩展性啥的都还不错。Spring Security倒是没用过，最后之所以没选择shiro而是选型了Spring Security主要还是由于这个也属于Spring大家庭的一员，个人比较主观地认为在spring cloud的大框架下这个框架应该兼容及扩展性会更好一些吧，毕竟出自一个全家桶（此处没有科学论证）。

 

      2.认识Oauth2，在这套框架已经投入运行很长时间后，作为设计者，我也没有认真理清过Oauth2到底是个啥，如今总结还是要好好理一遍的。

Oauth是一个开放标准（授权协议？），允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用，Oauth2是OAuth协议的下一版本，OAuth 2.0关注客户端开发者的简易性，同时为Web应用，桌面应用和手机，和起居室设备提供专门的认证流程。

该协议的认证流程：

名词解释：

• Resource Owner：资源所有者。即用户。
• Client：客户端（第三方应用）。如云冲印。
• Authorization server：授权（认证）服务器。即服务提供商专门用来处理认证的服务器。
• Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。
• Access Token：访问令牌。使用合法的访问令牌获取受保护的资源。

上图不太好理解，举例说明（来自某博客）

• 假如有一个云冲印的网站，可以将你存储在Google的照片冲印出来，用户为了使用该服务，必须让云冲印读取Google上的照片。为了拿到照片，云冲印必须得拿到一个用户的授权，如何获取这个用户授权呢？传统方法是用户将用户名和密码告诉云冲印，那么云冲印就可以自由无限制的访问了（相当于用户自己访问），这样显然是不行的，有几个严重的缺点：

  • 云冲印为了保存后续服务，会保存用户的密码，这样很不安全。
  • 云冲印拥有了获取用户存储在Google的所有资料的权力，用户没法限制云冲印得到的授权范围和授权有效期。
  • 用户只有修改密码，才能收回赋予云冲印的权力，但是如果还授权给了其他的应用，那么密码的修改将影响到所有被授权应用。
  • 只要有一个第三方应用程序被破解，就会导致用户密码泄漏，以及所有被密码保护的数据泄漏。（例子来自阮一峰-理解OAuth2.0）

可以看出，OAuth就是为解决如上例子而诞生的。

现在对Ouath2有了比较全面的理解了，总之它是一个公认标准一套认证协议，主要应用场景为像第三方授权这类，可以使用token的方式，让不同的应用能够授权访问，不用暴露用户原始密码，授权周期也可自行设置，一般不会很长，授权范围（授权域）也可指定，是相对比较安全的一套第三方授权流程协议。对于微服务，各个服务之间是相互独立的，而他们对用户来说确是一体，在他们之间的授权认证，同样可以采用oauth协议来完成。

3.认识JWT(JSON Web Tokens)，我理解是一种token规则吧，由3部分组成，各部分之间用.（点）分割，分别是：头信息.负载信息.签名。头信息一般包含两部分：token类型+加密算法；负载信息存放你实际想放的经常用的业务信息，比如用户名、所在组等（千万不能放私密信息如登录密码之类）签名主要是运用加密算法对负载信息进行的签名加密，以防止负载部分的数据被篡改，保证数据安全性。

使用JWT做认证token，可以实现服务间无状态token传递，不需要借助session或cookie，让分布式系统的权限认证简单化，不用再考虑不同服务间session丢失、共享等复杂问题了，同时，JWT是轻量级的，负载部分可以放一些常用非私密信息，减少一些不必要的数据库请求。

 

技术实现篇幅也比较长，看下一遍吧！

 

以上内容均属个人见解，非官方技术文档，仅做个人总结及经验分享之用，如有不符，欢迎留言指出共同探讨。