引言： 本文系《认证鉴权与API权限控制在微处事架构中的设计与实现》系列的第一篇，本系列估量四篇文章讲解微处事下的认证鉴权与API权限控制的实现。
1. 配景比来在做权限相关处事的开发，在系统微处事化后，原有的单体应用是基于Session的安适权限方法，不能满足现有的微处事架构的认证与鉴权需求。微处事架构下，一个应用会被拆分成若干个微应用，每个微应用都需要对访谒进行鉴权，每个微应用都需要明的当前访谒用户以及其权限。尤其当访谒来源不但是浏览器，还包孕其他处事的挪用时，单体应用架构下的鉴权方法就不是出格合适了。在微处事架构下，要考虑外部应用接入的场景、用户–处事的鉴权、处事–处事的鉴权等多种鉴权场景。
好比用户A访谒User Service，A如果未登录，则首先需要登录，请求获取授权token。获取token之后，A将携带着token去请求访谒某个文件，这样就需要对A的身份进行校验，并且A可以访谒该文件。
为了适应架构的变革、需求的变革，auth权限模块被单独出来作为一个根本的微处事系统，为其他业务service供给处事。
2. 系统架构的变换单体应用架构到漫衍式架构，简化的权限部分变革如下面两图所示。
（1）单体应用简化版架构图：
（2）漫衍式应用简化版架构图：
漫衍式架构，出格是微处事架构的长处是可以清晰的划分出业务逻辑来，让每个微处事承当职责单一的成果，终究越简单的对象越不变。
但是，微处事也带来了很多的问题。好比完成一个业务操纵，需要跨很多个微处事的挪用，那么如何用权限系统去控制用户对差别微处事的挪用，对我们来说是个挑战。当业务微处事的挪用接入权限系统后，不能拖累它们的吞吐量，当权限系统呈现问题后，不能梗阻它们的业务挪用进度，固然更不能转变业务逻辑。新的业务微处事快速接入权限系统相对容易把控，那么对付公司已有的微处事，如何能不窜改它们的架构方法的前提下，快速接入，对我们来说，也是一大挑战。
3. 技术方案这主要包孕两方面需求：其一是认证与鉴权，对付请求的用户身份的授权以及合法性鉴权；其二是API级另外操纵权限控制，这个在第一点之后，当鉴定完用户身份合法之后，对付该用户的某个具体请求是否具有该操纵执行权限进行校验。
3.1 认证与鉴权对付第一个需求，，笔者查询拜访了一些实现方案：
漫衍式Session方案
漫衍式会话方案道理主要是将关于用户认证的信息存储在共享存储中，且凡是由用户会话作为 key 来实现的简单漫衍式哈希映射。当用户访谒微处事时，用户数据可以从共享存储中获取。在某些场景下，这种方案很不错，用户登录状态是不透明的。同时也是一个高可用且可扩展的解决方案。这种方案的错误谬误在于共享存储需要必然掩护机制，因此需要通过安适链接来访谒，这时解决方案的实现就凡是具有相当高的庞大性了。
基于OAuth2 Token方案
跟着 Restful API、微处事的兴起，基于Token的认证此刻已经越来越遍及。Token和Session ID 差别，并非只是一个 key。Token 一般会包罗用户的相关信息，通过验证 Token 就可以完成身份校验。用户输入登录信息，发送到身份认证处事进行认证。AuthorizationServer验证登录信息是否正确，返回用户根本信息、权限范畴、有效时间等信息，客户端存储接口。用户将 Token 放在 HTTP 请求头中，倡议相关 API 挪用。被挪用的微处事，验证Token。ResourceServer返回相关资源和数据。
这边选用了第二种方案，基于OAuth2 Token认证的好处如下：
处事端无状态：Token 机制在处事端不需要存储 session 信息，因为 Token 自身包罗了所有用户的相关信息。
性能较好，因为在验证 Token 时不用再去访谒数据库或者长途处事进行权限校验，自然可以提升不少性能。
此刻很多应用都是同时面向移动端和web端，OAuth2 Token机制可以撑持移动设备。
OAuth2与Spring Security结合使用，有供给很多开箱即用的成果，大多特性都可以通过配置灵活的变换。
最后一点，也很重要，Spring Security OAuth2的文档写得较为详细。
oauth2按照使用场景差别，分成了4种模式：
授权码模式（authorization code）
简化模式（implicit）
暗码模式（resource owner password credentials）
客户端模式（client credentials）
对付上述oauth2四种模式不熟的同学，可以自行百度oauth2，阮一峰的文章有解释。常使用的是password模式和client模式。
3.2 操纵权限控制对付第二个需求，笔者主要看了Spring Security和Shiro。