私たちが最初に理解する必要があり、開発にサイン
OAuth（ここ記述するプロトコルをOAuthを参照するプロトコルをOAuth2プロトコル）、この紙で簡単にOAuth契約は、とに基づいてSpring Social、私は仕事をする必要がありますどのようなサードパーティのログインの開発を説明します。
A、OAuthプロトコルの紹介
OAuthのプロトコル生まれた背景
シナリオ例として、サードパーティサービスプロバイダは、画像に造園サービスを提供するために、そこにある、とあなたのイメージは、Baiduの雲のディスク上に格納され、その後、どのようにあなたの写真、それを美化するために、サードパーティのサービスプロバイダを行いますか？伝統的なアプローチは、許可のサードパーティのサービスプロバイダにBaiduのクラウドディスクのアカウントとパスワードを所有することで、彼はあなたの造園の写真の後にBaiduのクラウドディスクにログオンしますが、下に記載されているように、多くの問題を持っています。
- その後の継続的なサービスのためのサードパーティサービスプロバイダ、あなたのディスクBaiduのクラウドアカウントとパスワード情報を保存します。
- サードパーティサービスプロバイダは、アカウントとパスワードを取得するには、ユーザーがBaiduのクラウドディスクが第三者に公開されるすべての情報をユーザーと同じ権限を持ちます。
- サードパーティサービスプロバイダのサーバーを一度ハッキングされた、ユーザーは情報漏洩のリスクに直面するだろう。
- 唯一のサードパーティアプリケーションのBaiduのクラウドディスクを認証するために、ユーザのパスワードを変更することで回復し、その後、これはすべてのサードパーティが完全に回復ライセンスされます、特定のサービスの正常な行為を助長されていません。
OAuth出産は、上記の問題を解決することであり、それは非常にユーザーのプライバシー情報のセキュリティを向上させること、別の観点から自由に秘密の許可を実装しています。オープン認証は（OAuth）ユーザーは、サードパーティ製のアプリケーションへのユーザー名とパスワードを入力せずに、サイトのユーザーに保存されている（たとえば、写真、ビデオ、連絡先リストなど）にアクセスプライベートリソースへのサードパーティ製のアプリケーションを許可することを可能にするオープンスタンダードです。OAuthこれにより、ユーザーは特定のサービスプロバイダに保存されたデータにアクセスするためのユーザー名とパスワードの代わりにトークンを提供することができます。各トークンは、（例えば、時間の特定の期間の次の（例えば、ビデオ編集、ウェブサイト）特定のサイトのために許可された2時間内で）特定のリソースへのアクセス（例えば、単にビデオアルバム）。このように、OAuthユーザーがアクセスを、彼らは別のサービスプロバイダに格納特定の情報ではなく、すべてのコンテンツを、サードパーティのWebサイトを承認することができます。
OAuth全体的なデザインコンセプトが承認層を設定し、「クライアント」と「サービスプロバイダ」の間にあります（authorization layer）。「クライアント」は、ユーザとクライアント領域を区別するために、「サービスプロバイダ」ができる唯一のログイン認証層に直接ログインすることはできません。「クライアント」登録機関トークンを持つ層（token）、および異なるユーザのパスワード。ユーザーは、時間のログイン能力の認可レベルを指定し、トークンが有効であることができます。開放部に格納されている「クライアント」のユーザーデータへのトークンの範囲と有効性の権威の下に「クライアント」ログイン認証層、「サービスプロバイダ」の後。
役割関係OAuthプロトコル
投稿ここでOAuth役割グラフプロトコルを、私たちは様々な役割間の関係を説明し、図面の原則に従って行います。
Third-party application：本明細書では「クライアント」（として知られているサードパーティのアプリケーション、client）、サードパーティのサービスプロバイダの場合には、あります。HTTP service provider：HTTPISP、ここすなわちBaiduのクラウドディスクの場合、「サービスプロバイダ」と呼ばれます。Resource Owner：リソースの所有者は、本明細書では「利用者」と呼ばれますuser（）。User Agent：ユーザー・エージェントは、この記事では、ブラウザを指します。Authorization server：ハンドル認証サービスプロバイダ専用のサーバーが使用されていることを認証サーバ。Resource server：リソースサーバは、そのサーバでは、ユーザーが生成したリソースへのサービスプロバイダです。それは同じサーバにすることができ、認証サーバは、それは別のサーバーにすることができます。
役割との関係を説明してきたが、我々はに見てみるOAuth協定の実施プロセス：
- ユーザーがクライアントを開いた後、クライアントが許可を与えることをユーザーに要求します。
- ユーザーは、クライアント許可を与えることに同意します。
- クライアントは、認証サーバアプリケーショントークンに、前のステップで取得した認証を使用しています。
- クライアントを認証する認証サーバと、確認は、トークンを解放することに合意しました。
- クライアントは、トークンを使用して、リソースへのリソースサーバーへのアクセスに適用されます。
- リソースサーバーは、トークンが正しいことを認めて、クライアントにリソースを開くことで合意しました。
OAuthの認証モード
OAuth2.0議定書は、4つのライセンスモデルを提供し、彼らは以下のとおりです。
- 認証コードパターン
authorization code（） - 簡易モード
implicit（） - パスワードモード
resource owner password credentials（） - クライアント・モード
client credentials（）
このうち、認証コードモード（authorization code）関数は、最も完全な、最も厳格な認証プロセスモードです。これは、クライアントのバックエンドサーバーを介して「サービスプロバイダ」の認証サーバとの特徴、相互作用です。認可コードパターンフローチャート次のように
ステップ認証コードパターンは、実質的に、次のとおりです。
- ユーザーは、クライアントにアクセスすると、クライアントは、認証サーバーにユーザーに指示します。
- 認証サーバは、クライアント認証を許可するかどうか、ユーザーが選択したクライアントを依頼する認証要求を送信します。
- ユーザー認証が許可されたと仮定し、ユーザ認証サーバをあらかじめ「リダイレクトに指定されたクライアントを案内します
URI（」redirection URI、）認証コードと一緒に。 - クライアントは、認証コードを受け取り、それ以前の「リダイレクトを添付して
URI、認証サーバアプリケーショントークンに」。注：この手順は、クライアントのサーバー上でバックグラウンドで実行され、ユーザーには見えない、ユーザーは音痴ではありません。 - 認証コードとリダイレクトをチェックするために、認証サーバ
URI、確認後、アクセストークン（クライアントを送るaccess 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）
