Single-point log to achieve a common architecture
table of Contents
- 1. What is the single sign-on
- 2. User Login
- 2.1 authentication
- 2.2 License
- 2.3 architecture to achieve first-party login
- 2.4 architecture enables third-party login
- 2.5 Authorization difference between first-party and third-party login login
- 2.6 Login architecture for Summary
- 3. Access Control
- 3.1 Distributed authentication architecture
- 3.2 centralized authentication architecture
- 3.3 advantages and disadvantages of distributed and centralized authentication
- 3.4 access control granularity
- 3.4.1 Http method level
- 3.4.2 API interface level
- 3.4.3 API implementation level
- 4. Summary
- 5. References
Internet application development, user login and application access control service is a vital part, directly affect the safe operation of the application, but also affect the privacy of users, so users log on and access control are necessary Internet application development functional components, it relates to authentication, authorization, authentication and access control features four links. This paper comb single sign-on (single-sign-on) Internet application development technology architecture implementation, a single point of user login is also known as unified user login.
- Note 1: This article discusses the development of Internet applications, mainly refers to the web and mobile applications development of two technologies.
- Note 2: The definition of the concept discussed in this paper certification, authorization, authentication and access control from which this article . Therefore, before you read this article, it is recommended to read the articles before.
1. What is the single sign-on
SSO single sign-on user login achieve just this single function, it is more a technical architecture, a solution that provides a unified authentication, authorization, authentication and access control, to provide the corresponding component, user-friendly use, and development and application of fast access. Therefore, the single sign-on is not a simple login module.
Single sign-on, literally, it is to let users use the same account can access different application services, and users can log on once (once input user name and password) can achieve multiple authorization. Single sign-on can greatly facilitates the user's login operation. This is from the user's point of view single sign-on.
Another important demand for single sign-on also needs to be considered, the application is easy to use docking, single sign-on architecture must provide the appropriate client components and configurations, so that the application can simply, easily and quickly access single sign-on function, while permissions to achieve security control.
Therefore, the single sign-on technology as a security architecture that includes user login and access control needs two functions, authentication and authorization aspects involving the former, the latter involving authentication and access control sectors.
2. User Login
User login process generally involves two aspects of user authentication and authorization, these two segments often occur together, that identify the user, but also to complete the authorized user .
The provider login functional modules can be divided into a log and the log of the first to third party registers two types,
- First-party login: login service provided by the application itself. Because it is one's own and one's own login application, so log on mutual credibility between services and application services, which would greatly facilitate the authorization process.
- Sign in: application login services provided by third parties, the use of third-party user account login, such as through micro letter, QQ, Alipay account to log on and so on. At present most of the major Internet open platform using industry-standard OAuth 2.0 authorization code mode to achieve third-party login.
Log in Log in first-party and third-party, there is not much difference in user authentication technology, but there are differences authorization process. Specific authorization process and discuss the differences in architecture to achieve below.
2.1 authentication
In the development of the Internet, a common authentication modes,
- user name and password
- SMS verification code
- Two-dimensional code scanning mobile applications
- User gesture
- Time series based on one-time password associated with the user
In order to facilitate the discussion paper, will use simple http basic authentication (http basic authentication) way users log on, that is the way a user name and password. More authentication methods, generally can be achieved through the expansion interface identity provider.
2.2 License
Once the user logs in successfully, you can get to the appropriate authorization information.
In the field of Internet application development, implementation techniques authorized mainly include the following,
- Session mechanism through a web server, an access session to maintain the user's authorization information
- Cookie mechanism through a web browser, cookie maintains a website user authorization information
- Issued authorization token (token), a legally valid token maintains the user's authorization information
Both front is common in web development, needs the support of the browser. For mobile and other applications can not use the cookie scene, often be employed to achieve and carry the authorization token information in the request header manner.
In order authorization article support web applications and mobile applications, authorization information will authorization token (token) presented in the form of , for a web application, the authorization token carried in the request by a cookie, whereas for mobile applications, carries the header by way of in the request.
2.3 architecture to achieve first-party login
Because it is one's own sign-on implementation, so log on between services and application services trusted each other, which would greatly facilitate the authorization process.
In the first party scene log, it can generally be authorized in two ways,
- If the application accessed through a browser, it can be shared with authorized by cookie-domain
- If the application is not browser access, or can not, you can directly exchange authorized by a user name and password via cookie technology. It should be noted that the application service can get sensitive information such as user names and passwords, which is a prerequisite based on trusted applications.
Code implementation (to be developed)
A simple framework to achieve the following,
FIG bright red lines and squares of the required components and functions implemented in the single sign architecture, which includes,
- Single sign-on module: providing a user login interface, returns it possible to jump, issued authorization token (token), the checksum cancellation
- Web filter: obtaining authorization token request and check, if the request is legitimate through, otherwise it returns an error message.
For web applications, by sharing the cookie obtain the authorization of the way, the whole process interaction as follows,
- Users access the web service through a browser
- Back-end services in a common web filter check request, if the request is not an authorization token is found, then jump to the user login module, allowing users to log on
- User to enter a user name and password if the login is successful, cookie authorization token will be stored in your browser
- The user to jump back to the user access the page, then the request will automatically bring the authorization token cookie
- The web filter back-end service verification request authorization token in a cookie, if legitimate and valid, the user can access the back-end services, otherwise it returns an error message, the user is prompted to log in again.
- When users log off, web application service authorization token is stored in the browser clearing the cookie and log off redis tokens.
For mobile applications, obtain authorization by way of user name and password, the whole process interaction as follows,
- The user opens the mobile application, the application prompts the user to log on
- User to enter a user name and password if the login is successful, the token is returned to the mobile applications, storage, application storage space on the phone will be authorized.
- After entering the application, mobile application access back-end services, authorization token carried in the request header
- Back-end services in a common web filter header in the request for verification of the authorization token, if legitimate and valid, the user can access the back-end services, or prompt the user to log on.
- When users log off, the mobile application will remove the authorization token, and the token redis cancellation.
Since mobile applications do not like web applications, cookie through the browser mode automatically carry authorization information, the mobile application needs its own storage processing and authorization information request.
2.4 architecture enables third-party login
Login compared to the first party, third-party login biggest advantage that allows users to use a popular third-party account log in directly, such as micro letter, QQ, Taobao account, etc., eliminating the step of registering user accounts, but also spares user memory applications account password troubles to facilitate the rapid use of the user, thereby reducing the cost of user access.
For third-party login, currently the major Internet open platform they use industry-standard OAuth 2.0 authorization code mode. For OAuth 2.0 authorization code mode and more details will be discussed in another article, here it is not extended.
Code implementation (to be developed)
A simple framework to achieve the following,
FIG bright red lines and squares of the required components and functions implemented in the single sign-architecture including,
- OAuth 2.0 Authorization Server: provides user login authorization, jump achieve returns an authorization token (token) issuance, verification and cancellation
- Token Interface: a client calls, in exchange for an authorization token via authorization code
- Web filter: obtaining authorization token request and check, if the request is legitimate through, otherwise it returns an error message.
FIG There are two types of applications, web and mobile applications, two kinds of substantially the same way to obtain authorization.
For web applications, interactive follows the entire process,
- 用户通过浏览器访问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. 快速接入第三方用户 |