分布式权限控制

在互联网应用开发中，应用服务的用户登录和权限控制是至关重要的一个环节，直接影响到应用的安全运营，也影响到用户的隐私保护，因此用户登录和权限控制是互联网应用开发的必要功能组件, 其涉及到认证、授权、鉴权和权限控制四个功能环节。本文将梳理互联网应用开发中的单点登录（single-sign-on）技术架构实现，单点用户登录也被称为统一用户登录。

注1：本文讨论的互联网应用开发，主要是指web应用和移动应用开发两个技术领域。
注2：本文所讨论的认证、授权、鉴权和权限控制的概念定义来自其这篇文章。因此，在阅读本文之前，建议先请阅读前篇文章。

1. 什么是单点登录

单点登录不仅仅是实现用户登录这单一功能，它更是一个技术架构，一个解决方案，能够提供统一的认证、授权、鉴权和权限控制，提供相应的组件，方便用户的使用，以及应用的开发快速接入。所以，单点登录不是一个简单的登录模块。

单点登录，从字面来说，是让用户使用同一账号可以访问不同应用服务，而且用户只需登录一次（输入一次用户名和密码）便可实现多次授权。单点登录能够很大程度上方便用户的登录操作。这是从用户的角度出发来看单点登录。

单点登录还需要考虑的另外一个重要需求，是方便应用的对接使用，单点登录架构必须提供相应的客户端组件和配置，使得应用可以简单、方便、快速地接入单点登录功能，同时实现安全的权限控制。

因此，单点登录作为一个安全技术架构，其主要包括用户登录和权限控制两大功能需求，前者涉及认证和授权环节，后者涉及鉴权和权限控制环节。

2. 用户登录

用户登录的过程一般会涉及到用户认证和授权两个环节，这两个环节往往一并发生，即在确认用户身份的同时，也完成用户的授权。

根据登录功能模块的提供方，可以将登录划分为第一方登录和第三方登录两种类型，

第一方登录：应用的登录服务由自己提供。由于是己方登录和己方应用，所以登录服务和应用服务之间相互可信，这大大方便了授权过程。
第三方登录：应用的登录服务由第三方提供，使用第三方的用户账号登录，比如通过微信、QQ、支付宝账号进行登录等等。目前各大互联网开放平台大多采用业界标准的OAuth 2.0授权码模式实现第三方登录。

第一方登录和第三方登录，在用户认证技术的实现上没有太大差别，但是授权流程有区别。具体的授权流程和区别在下文的架构实现中讨论。

2.1 认证方式

在互联网开发中，常见的认证方式有，

用户名和密码
手机短信验证码
手机应用二维码扫描
用户手势
基于时间序列和用户相关的一次性口令

本文为了方便讨论，将使用简单的http基本认证（http basic authentication）方式进行用户登录，即用户名和密码的方式。更多的认证方式，一般可以通过identity provider的扩展接口来实现。

2.2 授权方式

一旦用户登录成功，即可获取到相应的授权信息。

在互联网应用开发领域，授权的实现技术主要包括如下几种，

通过web服务器的session机制，一个访问会话保持着用户的授权信息
通过web浏览器的cookie机制，一个网站的cookie保持着用户的授权信息
颁发授权令牌（token），一个合法有效的令牌中保持着用户的授权信息

前面两者常见于web开发，需要有浏览器的支持。而对于移动应用及其其它无法使用cookie的场景中，大多可以采用token的实现并通过header方式携带该授权信息在请求中。

本文为了同时支持web应用和移动应用的授权，授权信息将以授权令牌（token）形式颁发，对于web应用，该授权令牌通过cookie携带于请求中，而对于移动应用，则通过header方式携带于请求中。

2.3 第一方登录架构实现

由于是己方登录实现，所以登录服务和应用服务之间相互可信，这大大方便了授权过程。

在第一方登录的场景下，一般可以通过两种方式获得授权，

若应用通过浏览器访问，则可以通过同域cookie方式实现共享授权
若应用不是浏览器访问，或者无法通过cookie技术，则可以直接通过用户名和密码来换取授权。需要注意的是，应用服务可以拿到用户名和密码等敏感信息，这是基于可信应用的先决条件。

代码实现（待开发）

一个简单的架构实现如下，

图中亮红色线和方格为单点登录架构所需实现的组件和功能，其主要包括，

单点登录模块：提供用户登录界面，实现跳转返回，授权令牌（token）的颁发、校验和注销
Web filter：获取请求中的授权令牌并校验，若合法则通过请求，否则返回错误消息。

对于web应用，通过共享cookie的方式获取授权，整个流程交互如下，

用户通过浏览器访问web服务
后端服务中一个通用的web filter校验请求，若发现请求中没有授权令牌，则跳转至用户登录模块，让用户进行登录
用户输入用户名和密码，若登录成功，则将授权令牌存储在浏览器的cookie中
将用户跳转回用户的访问页面，此时请求中cookie将自动带上授权令牌
后端服务的web filter校验请求cookie中的授权令牌，若合法且有效，则用户可以正常访问后端服务，否则返回错误消息，提示用户再次登录。
用户注销登录时，web应用服务将存储在浏览器cookie中的授权令牌清除，并注销redis中的令牌。

对于移动应用，通过用户名和密码的方式获取授权，整个流程交互如下，

用户打开移动应用，应用提示用户登录
用户输入用户名和密码，若登录成功，则将授权令牌返回给移动应用，存储在手机上的应用存储空间。
进入应用后，移动应用访问后端服务，授权令牌携带在请求header中
后端服务中一个通用的web filter对请求header中的授权令牌进行校验，若合法且有效，则用户可以正常访问后端服务，否则提示用户登录。
用户注销登录时，移动应用将授权令牌清除，并注销redis中的令牌。

由于移动应用无法像web应用一样，通过浏览器cookie的方式自动携带授权信息，移动应用需要自己处理授权信息的存储和请求发送。

2.4 第三方登录架构实现

相比于第一方登录，第三方登录最大的好处在于，可以让用户使用一个常用的第三方账号直接登录，例如微信、QQ、淘宝账号等，省去了用户注册账号的步骤，也免去用户记忆各种应用账号密码的烦恼，方便了用户的快速使用，进而降低用户接入成本。

对于第三方登录，目前各大互联网开放平台大多采用业界标准的OAuth 2.0授权码模式。对于OAuth 2.0的授权码模式和更多详细介绍将有另外一篇文章讨论，这里对其不扩展。

代码实现（待开发）

一个简单的架构实现如下，

图中亮红色线和方格为单点登录架构所需实现的组件和功能，其包括，

OAuth 2.0授权服务器：提供用户登录授权，实现跳转返回，授权令牌（token）的颁发、校验和注销
Token接口：用于客户端调用，通过授权码换取授权令牌
Web filter：获取请求中的授权令牌并校验，若合法则通过请求，否则返回错误消息。

图中有两种应用类型，web应用和移动应用，两种获取授权方式基本一样。

对于web应用，整个流程交互如下，

用户通过浏览器访问Web服务
后端服务中一个通用的web filter校验请求，若发现请求中没有授权令牌，则跳转至第三方用户登录服务
在第三方登录服务中，用户输入用户名和密码，若登录成功，则跳转回web应用，并返回授权码
Web应用将获取到的授权码，调用后端Token接口，该接口将根据授权码+应用ID+应用Secret，向第三方申请授权令牌，若一切正常，第三方颁发授权令牌给Web应用，Web应用将获取到的授权令牌存储在浏览器的cookie中。
将用户跳转回用户的初始访问页面，此时请求中cookie将自动带上授权令牌
后端服务的web filter校验请求cookie中的授权令牌，若合法且有效，则用户可以正常访问后端服务，否则返回错误消息，提示用户再次登录。
用户注销登录时，web应用服务将存储在浏览器cookie中的授权令牌清除，并注销redis中的令牌。

移动应用和web应用的流程类似，整个流程交互如下，

用户打开移动应用，应用提示用户登录，并将用户导向第三方登录服务
在第三方登录服务中，用户输入用户名和密码，若登录成功，则跳转回移动应用，并返回授权码给移动应用。
移动应用将获取到的授权码，调用后端Token接口，该接口将根据授权码+应用ID+应用Secret，向第三方申请授权令牌，若一切正常，第三方颁发授权令牌给移动应用，移动应用将获取到的授权令牌存储在手机上的应用存储空间。
进入应用后，移动应用访问后端服务，授权令牌携带在请求header中
后端服务中一个通用的web filter对请求header中的授权令牌进行校验，若合法且有效，则用户可以正常访问后端服务，否则提示用户登录。
用户注销登录时，移动应用将授权令牌清除，并注销redis中的令牌。

2.5 第一方登录和第三方登录的授权区别

第一方登录和第三方登录之间最大的区别在于授权流程。

第一方登录在用户被认证之后，即刻颁发授权令牌，应用服务一般无需介入授权流程。而第三方登录在用户认证之后，先颁发给授权码给应用服务，应用服务还需根据这个授权码去换取授权令牌，换句话说，应用服务需介入授权流程。

这里有个问题是，为什么在第三方登录中，应用服务会被介入授权流程？主要原因是在第三方登录场景中，除了用户需要被认证，应用服务本身也需要被认证。而在第一方登录场景，只需用户认证，应用服务本身是可信的，其无需被认证。

2.6 登录架构实现小结

为了对比上述两个登录架构实现的不同之处，下面将各自的特点小结为下表，

	第一方登录架构	第三方登录架构
登录功能	由己方提供	由第三方提供使用第三方的用户账户
登录实现	通过http basic auth	OAuth 2.0授权码模式
应用是否可信	可信，应用可以接触用户密码等敏感信息，应用本身无需认证	不可信
应用是否需要认证	否	是
应用是否可以接触用户密码等敏感信息	是	否
授权过程	登录成功后颁发token	1. 登录成功后返回授权码给应用 2. 应用根据授权码和应用ID换取token
Web页面的服务请求	通过cookie带上token	通过cookie带上token
移动应用的服务请求	通过header带上token	通过header带上token

3. 权限控制

在互联网应用开发中，安全控制在后端服务中实现。整个权限控制的过程一般会涉及到鉴权和权限控制两个环节。

鉴权的实现方式一般有两种，

通过授权服务器：由于授权令牌是由授权服务器颁发的，所以由授权服务器校验也是自然而然的事情。这种方式会导致授权服务器的访问热点问题，为了缓解热点，缓存是必要配置。
通过加解密：通过授权令牌的加解密方式，确认令牌的合法性。即，授权服务器颁发一个通过公钥加密的授权令牌，在校验的时候若能够通过私钥解密，则该令牌为合法令牌。这种方式有一个缺点是，一旦令牌注销失效后，信息无法及时通知到解密方。对令牌的注销时效性要求不高的场景下，可以使用这种方式，其大大缓解了授权服务器的访问热点问题。

若根据鉴权的架构方式，则可分为分布式和集中式两大类，

分布式：通过后端web服务的filter实现分布式控制，在各个服务应用的运行实例中进行鉴权
集中式：通过网关实现集中式控制，在访问流量的入口进行鉴权

鉴权后访问控制粒度从大到小有如下三种分类，

Http方法级别
API接口级别
API实现级别

下面将对鉴权的架构实现和控制粒度进行详细讨论。

3.1 分布式鉴权架构

分布式鉴权的架构如下图，

在web应用开发中，可以通过web应用服务的filter功能，对所有请求中的授权令牌进行校验，实现分布式鉴权。分布式鉴权实现简单，可以快速实现并使用，但随着应用服务架构的水平和垂直扩展，filter的升级将会成为头痛的问题。

3.2 集中式鉴权架构

集中式鉴权的架构如下图，

通过网关，在访问流量的入口，对所有请求中的授权令牌进行校验，实现集中式鉴权。集中式鉴权减轻了应用服务的接入成本，但会增加了网关的性能负荷。

3.3 分布式和集中式鉴权的优缺点

分布式鉴权和集中式鉴权有各自的优缺点小结为下表，

	分布式鉴权	集中式鉴权
优点	简单，可以分散校验热点	应用服务接入成本低，方便鉴权管理
缺点	filter版本升级困难，需要对所有应用服务进行依赖更新	需要网关的支持，并且鉴权操作将增加网关的性能负荷
应用场景	简单的互联网web应用开发	大型互联网web应用开发

3.4 访问控制的粒度

鉴权后就会得到请求访问的权限，接下来则是根据权限来控制请求访问的允许或禁止。

根据访问控制粒度从大到小，可划分出如下几个控制级别，

Http方法级别
API接口级别
API实现级别

3.4.1 Http方法级别

若web应用服务是按照Restful的规范来开发接口服务，则可以根据Restful的定义对Http的不同方法实现不同的访问控制。

根据Restful的规范定义，Http方法具有如下安全性和幂等性的特点，

HTTP方法	Restful定义	安全性	幂等性
GET	获取资源	是	是
POST	创建资源	否	否
PUT	更新资源	否	是
DELETE	删除资源	否	是
HEADER	资源元信息	是	是
OPTIONS		是	是

表中，安全性和幂等性的概念如下,

安全性是指该方法不改变资源的状态，即不改变后台数据
幂等性是指该方法执行的同一操作多次，其结果保持一致

可以看到，对于安全的HTTP方法，比如GET操作，其访问控制可以宽松。而对于一些非安全操作，则需要根据不同权限来控制访问请求。在实际应用过程中，可以执行如下的权限控制规则，

匿名用户：可以执行GET请求
普通登录用户：可以执行GET、POST、PUT请求
管理员：可以执行所有类别请求

总的来说，根据Http请求的方法和URI进行访问控制。

3.4.2 API接口级别

这个权限控制的粒度深入到代码控制层（Controller），不同的权限，可以访问不同的API接口。

一个spring mvc的代码样例如下，

@Controller
public class TokenApp {

    @PreAuthorize("hasAuthority('ROLE_ADMIN')")
    public Principal getUserInfo(Principal me){
        return me;
    }

}

上面的代码表示，具有管理员角色的权限才能获取当前用户信息。

这个粒度的权限访问控制基本可以满足大多数应用场景需求。

3.4.3 API实现级别

在应用的实现级别进行控制，这个控制粒度非常细，其根据不同权限返回不一样的调用结果，例如，同样是查看学生列表，若是班主任，则返回一个班的学生列表，若是校长，则返回一个学校的学生列表。

4. 小结

本文主要从用户登录和权限控制两大功能方面梳理其架构实现，这些实现可以结合实际的应用场景，进行相应的匹配。

	第一方登录	第三方登录
分布式权限控制	1. 简单web应用场景 2. 登录服务和应用服务相互可信 3. 登录服务和应用服务同域，可以授权共享	1. 简单web应用场景 2. 登录服务和应用服务相互不可信 3. 登录服务和应用服务不同域，各自独立开发部署，无法授权共享 4. 应用和登录服务模块彻底解耦，通过跨域跳转实现用户登录。
集中式权限控制	1. 大型web应用场景，有网关组件部署	1. 大型web应用场景，有网关组件部署 2. 快速接入第三方用户

标签：分布式权限控制

单点登录的通用架构实现