Spring Security technology stack development enterprise-class authentication and authorization (xiii) Spring Social integrate third-party login verification development process introduced

Sign in development, we must first understand the OAuthprotocol (herein describes the OAuthprotocol refers to the OAuth2protocol), this paper briefly OAuthagreement, and based on Spring Socialto explain the development of third-party login What do I need to do work.

A, OAuth protocol Introduction

OAuth protocol born background

As an example scenario, there is a third party service provider, to provide landscaping services to pictures, and your images are stored on Baidu cloud disk, then how do the third-party service providers to beautify your picture it? The traditional approach is to own Baidu cloud disk account and password to authorized third-party service provider, he logged on to Baidu cloud disk after pictures of your landscaping, but do have a lot of problems, as listed below:

• Third party service provider for a subsequent continuous service, will save your disk Baidu cloud account and password information;
• Third party service provider to obtain an account and password, and users will have the same rights as all information users Baidu cloud disk will be exposed to a third party;
• Third-party service provider's server was hacked once, then the user will face the risk of information leakage;
• Only to recover by modifying the user password to authorize Baidu cloud disk for third-party applications, then this will all third-party licensing fully recovered, is not conducive to the normal conduct of certain services.

OAuthThe birth is to solve the above problems, it implements the free secret authorization from another point of view, greatly improving the security of user privacy information. Open Authorization ( OAuth) is an open standard that allows users to allow third-party applications to access private resources (such as photos, videos, contact lists) stored on the user of a site without a user name and password to third-party applications . OAuthIt allows users to provide a token instead of a user name and password to access their data stored in a particular service provider. Each token is authorized for a particular site (for example, video editing website) (for example, the next in a specific period of time 2within hours) access to specific resources (for example, just a video album). In this way, OAuthallowing users to authorize third-party website to access certain information they store in another service provider, not all content.

OAuthThe overall design concept is between the "client" and "service providers", set up an authorization layer ( authorization layer). "Client" can not log in directly to "service providers" can only login authorization layer, in order to distinguish between the user and the client area. "Client" Registration Authority layer with a token ( token), and passwords for different users. Users can login time, specify the authorized level of competence and the token is valid. After the "client" login authorization layer, "Service Provider" under the authority of the scope and validity of the token to the "client" user data stored in the open section.

Role relationships OAuth protocol

Here posted a OAuthrole graph protocol, we describe the relationship between the various roles and perform in accordance with the principles of drawing.

• Third-party application: Third-party applications, herein known as "client" ( client), that is, on a case of third-party service providers.
• HTTP service provider: HTTPISP, herein referred to as "service provider", ie a case of Baidu cloud disk.
• Resource Owner: Resource owners, herein called "user" user( ).
• User Agent: User agent, this article refers to the browser.
• Authorization server: An authentication server that handles authentication service provider dedicated server is used.
• Resource server: Resource server, that server is a service provider to store user-generated resource. It authentication server, which can be the same server, it can be a different server.

Having described the role relationships, we take a look into OAuththe implementation process of the agreement:

• After a user opens a client, the client asks the user to give authorization.
• User agrees to give the client authorization.
• Clients use the authorization obtained in the previous step, to the authentication server application token.
• After authentication server to authenticate the client, confirmation, agreed to release the token.
• The client uses the token, apply to the resource server access to resources.
• Resource server acknowledges the token is correct, agreed to open the resource to the client.

OAuth authorization mode

OAuth2.0Protocol provides four licensing model, they are:

• Authorization code pattern authorization code( )
• Simplified mode implicit( )
• Password mode resource owner password credentials( )
• Client mode client credentials( )

Among them, an authorization code mode ( authorization code) function is the most complete, most rigorous authorization process mode. It is characterized, interact with the "Service Provider" certification server through the client's back-end server. Authorization code pattern flowchart as follows:

Step authorization code pattern substantially as follows:

• Users access the client, the client will direct users to the authentication server.
• The authentication server sends an authorization request to ask the client, the user selects whether to grant the client authorization.
• Assume that the user authorization is granted, the user authentication server will guide the client designated in advance "redirect URI" ( redirection URI), together with an authorization code.
• The client receives an authorization code, attach the earlier "redirect URI" to the authentication server application token. Note: This step is done in the background on the client's server, invisible to the user, the user is no sense of.
• The authentication server to check the authorization code and redirect URI, after confirmation, send the access token (the client access token) and updates the token ( refresh token).

简化模式（implicit grant type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了“授权码”这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。
简化模式的基本步骤如下：

• 客户端将用户导向认证服务器。
• 用户决定是否给于客户端授权。
• 假设用户给予授权，认证服务器将用户导向客户端指定的“重定向URI”，并在URI的Hash部分包含了访问令牌。
• 浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。
• 资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。
• 浏览器执行上一步获得的脚本，提取出令牌。
• 浏览器将令牌发给客户端。

密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向“服务商提供商”索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。
密码模式的基本步骤如下：

• 用户向客户端提供用户名和密码。
• 客户端将用户名和密码发给认证服务器，向后者请求令牌。
• 认证服务器确认无误后，向客户端提供访问令牌。

客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。
客户端模式的基本步骤如下：

• 客户端向认证服务器进行身份认证，并要求一个访问令牌。
• 认证服务器确认无误后，向客户端提供访问令牌。

这里对OAuth协议的简单介绍参考了阮一峰的网络日志中的一篇文章《理解OAuth2.0》，该文章详细介绍了协议中信息传输的相关参数，感兴趣的可以去学习一下，这里仅仅是对OAuth协议进行简要介绍。

二、Spring Social简介

Spring Security认证成功的标准是在SecurityContext中存储了用户相关的Authentication实例对象，也就是说当一个用户提供了正确信息给系统，系统带着用户的信息完成了一系列的校验后，校验通过后，将生成用户信息相关的Authentication存储到SecurityContext中。那么如果使用第三方登录，使用第三方如QQ、微信的用户信息进行登录验证，这是如何做到的呢？道理也是一样的，就是拿到第三方的用户信息，使用第三方的用户信息构建Authentication实例对象，并存储到SecurityContext中，而在获取第三方用户信息的时候，必须遵循OAuth协议，OAuth协议规定的流程，必须严格执行，那么Spring Social的作用就凸显了，它诞生的一个很大作用就是封装了OAuth协议规定的基础流程。

Spring Social已经将前五步封装了，开发者开发特定第三方登录验证，只需要实现第六步和第七步即可，最后组成一个SocialAuthenticationFilter集成到整个验证的过滤器链上，当用户选择第三方登录的时候，就会被该过滤器拦截，在过滤器中获取第三方用户信息，构建用户信息相关的Authentication实例对象并存储到SecurityContext中。

具体的开发原理和流程，我们一起跟着下面的图片，来一步一步讲解。

我们讲解的顺序是从右往左讲，对图片上的每一个类或者接口都进行一个详细的讲解。

• ServiceProvider：它是一个接口，在包org.springframework.social下，它的存在就是为了适配不同的第三方服务提供商，比如QQ、微信等。如果我们需要开发QQ登录，那么我们就需要为QQ提供一个特定的ServiceProvider，而这个接口下有一个抽象实现AbstractOAuth2ServiceProvider，我们为QQ写ServiceProvider的时候只需要继承AbstractOAuth2ServiceProvider类即可。抽象类AbstractOAuth2ServiceProvider有两个属性OAuth2Operations和Api，接下来分别介绍它们的作用。
• OAuth2Operations：它是一个接口，在包org.springframework.social.oauth2下，它封装了OAuth协议的前五步，也就是用户授权，直到应用拿到第三方应用（QQ、微信）的访问令牌，该接口有一个实现类OAuth2Template，OAuth2Template完成了访问第三方应用认证服务器、获取授权码、携带授权码申请令牌、获取令牌等核心步骤，在这里，我们需要做的仅仅是配置一些特定第三方认证服务器的URL即可，因为整个流程是遵循OAuth协议的，所以这些核心步骤需要携带的参数都是公共的，对开发者透明的。
• Api：在包org.springframework.social下有一个ApiBinding接口，它主要是为了帮助开发者完成第六步的一个接口，由于每一个第三方应用的用户信息都是有区别的，比如用户头像的字段，在QQ里面叫head_image，也许到了微信里面，就叫image了，所以这里是一个个性化的开发区域，需要对每一个第三方服务提供商开发一个特定的类来实现用户数据的获取，这里Spring Social提供了一个抽象类AbstractOAuth2ApiBinding，尽可能地减少我们的开发成本，我们在开发获取用户信息的代码的时候，只需要继承这个抽象类即可。

以上的三段描述将与第三方服务提供商相关类和接口介绍完毕，那么我们与第三方服务提供商交互完毕，拿到了用户数据以后，那么该如何完成认证的操作呢？那么就得继续来介绍上图左边的相关类和接口。

• Connection：它是一个接口，在包org.springframework.social.connect下，它封装了与用户相关的信息，这些信息，比如DisplayName（显示名称），ProfileUrl（主页地址），ImageUrl（头像地址）等基本信息，这些信息是Spring Social所规定的用户信息（固定字段），它有一个实现类OAuth2Connection，也就是说我们如何将拿到的用户信息转换成OAuth2Connection所封装的用户信息呢？那么就必须得讲解一下生成Connection实现类对象的工厂ConnectionFactory。
• ConnectionFactory：它是一个接口，在包org.springframework.social.connect下，它有一个实现类OAuth2ConnectionFactory，该类就可以完成对Connection的创建，而在OAuth2ConnectionFactory的构造方法中，就用到了ServiceProvider和ApiAdapter。ServiceProvider就是我们之前为特定第三方服务提供商编写的代码，它提供了从第三方服务提供商获取用户信息，ApiAdapter是一个适配器，主要是完成了从第三方服务提供商获取到的用户信息到Spring Social规定的用户信息的转换工作，这个适配器也是需要我们自己编写的内容之一。那么有了ServiceProvider和ApiAdapter，就可以构建OAuth2ConnectionFactory对象，那么就可以来创建Connection的实现类对象了。
• UserConnection：UserConnection是Spring Social规定的一张数据库表。当用户在登录系统的时候，选择的是QQ登录或者微信登录，那么系统是如何辨别该用户使用QQ号登录的时候，它对应到系统中的一个用户呢？也就是说用户使用的第三方账户A登录，系统是如何做到与业务系统里面的“张三”关联起来的呢？那么这个功劳就应该归属于UserConnection表了，它就是专门用来记录第三方账户和业务系统内的账户之间的关系的一张表。
• UsersConnectionRepository：它是一个接口，在包org.springframework.social.connect下，它专门封装了UserConnection表的一些基础操作，他有一个默认实现类JdbcUsersConnectionRepository，在该类的包下，有一个JdbcUsersConnectionRepository.sql文件，这个文件中有创建表的语句，需要我们自己拷贝出来创建对应的数据库表，该表名可以是UserConnection，也可以在该名称之前加上一个前缀。这里贴出创建表的语句：

create table UserConnection (userId varchar(255) not null,
	providerId varchar(255) not null,
	providerUserId varchar(255),
	rank int not null,
	displayName varchar(255),
	profileUrl varchar(512),
	imageUrl varchar(512),
	accessToken varchar(512) not null,
	secret varchar(512),
	refreshToken varchar(512),
	expireTime bigint,
	primary key (userId, providerId, providerUserId));
create unique index UserConnectionRank on UserConnection(userId, providerId, rank);

这里就完成了对Spring Social集成第三方登录需要开发内容的基本介绍，我们将在本系列教程的第十四篇文章中介绍Spring Social集成QQ登录验证方式，将在第十五篇文章中介绍Spring Social集成微信登录验证方式，敬请期待。

Spring Security技术栈开发企业级认证与授权系列文章列表：

Spring Security技术栈开发企业级认证与授权（一）环境搭建
Spring Security技术栈开发企业级认证与授权（二）使用Spring MVC开发RESTful API
Spring Security技术栈开发企业级认证与授权（三）表单校验以及自定义校验注解开发
Spring Security技术栈开发企业级认证与授权（四）RESTful API服务异常处理
Spring Security技术栈开发企业级认证与授权（五）使用Filter、Interceptor和AOP拦截REST服务
Spring Security技术栈开发企业级认证与授权（六）使用REST方式处理文件服务
Spring Security技术栈开发企业级认证与授权（七）使用Swagger自动生成API文档
Spring Security技术栈开发企业级认证与授权（八）Spring Security的基本运行原理与个性化登录实现
Spring Security技术栈开发企业级认证与授权（九）开发图形验证码接口
Spring Security技术栈开发企业级认证与授权（十）开发记住我功能
Spring Security技术栈开发企业级认证与授权（十一）开发短信验证码登录
Spring Security技术栈开发企业级认证与授权（十二）将短信验证码验证方式集成到Spring Security
Spring Security技术栈开发企业级认证与授权（十三）Spring Social集成第三方登录验证开发流程介绍
Spring Security技术栈开发企业级认证与授权（十四）使用Spring Social集成QQ登录验证方式
Spring Security技术栈开发企业级认证与授权（十五）解决Spring Social集成QQ登录后的注册问题
Spring Security技术栈开发企业级认证与授权（十六）使用Spring Social集成微信登录验证方式

示例代码下载地址：

项目已经上传到码云，欢迎下载，内容所在文件夹为chapter013。

更多干货分享，欢迎关注我的微信公众号：爪哇论剑（微信号：itlemon）