资源服务器(Resource Server):保存用户的资源,验证令牌,最终我们第三方应用发请求的时候是发往资源服务器的,会带着认证服务器发出去的Token,由资源服务器去验证Token,如果验证通过了就会把资源给他.虽然在逻辑上认证与资源服务器是两个角色,但是在物理上它们可以是一台机器,一个应用.

资源所有者(ResourceOwner):用户

第三方应用(Client):第三方服务提供商

1.3 OAuth协议运行的流程

第二种统一授权有四种模式:授权码模式,密码模式,客户端模式,简化模式

1.3.1 授权码模式

授权码模式是这四种模式中功能最完整,流程最严密的授权模式.现在互联网上的服务提供商,如微博,微信,QQ,百度,淘宝全都是采用这个授权码模式来完成整个OAuth流程的.

如果第三方客户端需要用户授权会将用户导向认证服务器,用户用意授权的动作会在认证服务器上来完成,如果用户同意授权,那么认证服务器会将用户重新倒回到第三方应用上去,倒回到哪个地址上是第三方应用与认证服务器事先商量好的.同时会携带一个授权码,第三方应用在收到授权码后,它会拿着授权码向认证服务器申请令牌,这一步是在客服端内部完成的,对客户不可见,认证服务器会核对授权码是不是我第三步发回去的,如果是确认无误,则会发放令牌(Token)

授权码模式的特点

1.在第三步会返回授权码将它与其它模式分开.

2.用户授权是在认证服务器上完成的,密码模式和客户端模式,都是在第三方应用上完成的.完成后第三方应用向认证服务器申请令牌的时候带着一些信息说用户授权给我了,请求令牌,但是认证服务器不能确定用户是否是真的授权了,还是是伪造的.

3.从认证服务器返回的不是令牌而是授权码,要求第三方应用必须有服务器.而不是仅仅返回给浏览器凭借脚本去执行就行了.

第二章 Spring Social的基本原理

上面我们也了解到了,OAuth协议实际上是一个授权协议,让用户不将用户名密码交给第三方应用的情况下,让第三方应用有权限访问用户存储在服务提供商上的一些资源.

前面讲SpringSecurity的时候讲过,当你向SecurityContext里面放入一个经过验证的Authentication的时候,你就登陆成功了,如果我们引导用户走完下图中的所有内容,就相当于用户用服务提供商上的基本信息登陆了我们的第三方应用.

Spring Social把整个流程封装到了一个叫SocialAuthenticationFilter的过滤器里面,然后把过滤器嫁到了SpringSecurity的过滤器上,当你访问某个请求时,SocialAuthenticationFilter会把这个请求拦下来,带着你把整个流程走完.

下面将介绍SpringSocial是如何把这样一个流程封装到接口和类里面的.以及类与依赖的调用关系.

1. 我们是与服务提供商打交道的,所以要介绍的第一个接口是ServiceProvider,它就是服务提供商的抽象类,针对每一个具体的服务提供商,它们都要提供一个接口的具体的实现,SpringSocial提供了一个AbstractOAuth2ServiceProvider,它帮我们实现了一些固有的东西,当我们提供QQ的服务提供商的实现时,我们只要继承这个抽象类就可以了(我们现在用的都是OAuth2协议,国外的有一些OAuth1协议,我们在这里说到的都是OAuth都是2协议).

在服务提供商六步中,第一步到第五步都是标准的流程,第六步是个性化的流程,第六步每个服务提供商提供的数据信息与数据结构都是不一样的,针对这两块,在ServiceProvider里分别有两个封装

第一个接口是OAuth2Operations,这个接口封装了第一步到第五步这样一个标准的OAuth协议的处理流程,SpringSocial给我们提供了一个实现OAuth2Template.

第二个接口是Api,第二个接口实际上没有一个明确的接口,因为每一个服务提供商对用户的基本信息调用都是有去别的,所以我们要自己写一个接口来获取用户信息.这里SpringSocial也提供了一个抽象类,叫做AbstractOAuth2ApiBinding来帮助我们更快的去实现我们的第六步所需Api接口的实现.

2. 第七步我们是在第三方应用内部完成的,第一个接口叫做Connetion,这个Connetion不是数据库的Connetion,它的作用是封装我们前六步获取到的用户信息,实际代码中用到的实现类是OAuth2Connection.

3. Connection由ConnetionFactory创建,我们实际用到的类是OAuth2ConnetionFactory,这个工厂负责创建我们的Connetion实例,为了创建这个对象一定要走前面的流程,就一定需要我们的ServiceProvider,所以ConnetionFactory中包含ServiceProvider实例.

这里的问题是Connetion的数据结构是固定的,而根据服务提供商的不同我们获取的信息的数据结构不是固定的,如何将不固定的数据结构转换为固定的呢,可以用ApiAdapter的接口的实现来完成.顾名思义就是在Api和Connetion之间做一个适配,

4. connetion封装的是服务提供商里的用户信息,在业务中我们一般会把业务系统中的用户存在user数据库表中,我们怎么把user表中的用户与connetion中的用户关联到一起呢,即你怎么知道这个QQ是数据库中的张三登陆的呢?这个对应关系是对应在数据库中的UserConnetion表中,这个表由UsersConnectionRepository接口来操纵

SpringSocial的基本概念就是上面那些,都是我们写代码的时候要涉及到的一些概念,就像我们之前写表单登陆成功的逻辑要实现个接口SuccessHandler,与那个类似,上面的也是一些零散的接口,我们去实现它,这样我们才能把我们自己QQ登陆与微信登陆的逻辑架在SpringSocial上,实际上SpringSocial已经把绝大多数第三方登陆的逻辑所需要实现的代码都已经实现了,我们在这里做的只是与我们自己做的相关的一些东西.我们把这个实现了就可以把整个流程跑起来,跑起来后再进入SpringSocial看看它都做了什么.

第三章实现QQ登陆

写的流程:Api->OAuth2Operations->ServiceProvider->ApiAdaper->ConnectionFactory->Connection->UsersConnectionRepository

3.1 Api

新建包social.qq.api

QQUserInfo:从官网拷贝的返回结果

QQ接口:

实现类:

appid是授权码,format是替换字符串中的%s

object.mapper是把json转换成指定类型的对象

实现类介绍:

打开AbstractOAuth2ApiBinding

accessToken是存储前五步获得令牌的,因为每个人获取到的令牌都是全局变量,所以QQImpl不是单例对象.restTemplate是帮我们向服务商发送http请求的.

查找qq登陆api,openid相当于用户在qq中的唯一标识.

openId的请求的返回结果:

通过如下查询就可以访问用户数据了:

如果访问正确会返回的结果示例:

错误的返回示例:

当选择了ACCESS_TOKEN_PARAMETER策略后,根据token去查询时会将Token作为查询参数写在url上.

QQUserInfo:

从官网返回的信息中直接拷贝

3.2 QQServiceProvider

是为了处理一到五步的请求,涉及到了一些信息,如将用户导向服务器的地址.

新建connet包,建立新的类QQServiceProvider继承AbstractOAuth2ServiceProvider<S>,有一个泛型,泛型是刚才的Api QQ.

QQImpl是一个多实例的,所以我们这里需要new,appId需要我们自己处理,到时候需要的时候把AppId传进来就好了.对于QQ来说有唯一的appid.

为了继承抽象类,还要实现一个构造函数,在构造函数中返回OAuth2Template,为了返回OAuth2Template必须返回四个参数.

clientId,clientSecret,authorizeUrl,accessTokenUrl

appId与appSecret是服务提供商针对我们的项目给我们的.

authorizeUrl是第一步将用户导向服务器的url

accessTokenUrl是第四步是申请令牌时需要的url.

3.3 QQAdapter

新建类QQAdapter实现ApiAdapter<S> ,泛型为之前的Api,这里是QQ,实现后需要满足一些方法.

test方法表示是否能连通

setConnetionValues在Api与Connetion之间做一个适配

ProfileUrl是个人主页.fetchUserProfile通过Api拿到标准用户信息,updateStatus在某些网站才有这个概念,发message,等等更新微薄的.这里就不用做了

3.4 ConnectionFactory

新建类QQConnectionProvider需要继承OAth2ConnetionFacory<S>,泛型是API,这里是QQ.

继承后需写构造函数,providerId是供应商的唯一标识,serviceProvider是我们上面写的,第三个参数是我们上面的QQAdapter.

connection不用我们处理,由我们之前写的代码构建出来.

3.5 UsersConnectionRepository

要把我们的数据保存到我们的数据库中,需要UsersConnectionRepository,这个已经提供给我们了但是需要配置一下.

新建UsersConnectionRepository需要三个参数,dataSource就是数据库的配置,connectionFactoryLocator的作用是查找项目中的connectionFactory(项目中可能有其它的factory如qq微信的),textencrypt是加密解密用的工具.

UsersConnectionRepository是为了操作数据库表,所以我们要新建数据库表,可以加个前缀,但是要repository.setTablePrefix

UserId是用户的ID,providerId是服务提供商的id,第三个是openid,这个为联合主键.

3.5.1 从userId转换为用户信息

之前我们说过UserDetailsService,根据用户名去查找校验,如果查找成功了就封装到UserDetails中,并返回UserDetails,再放到session中表示登陆成功了.

与此机制类似,SpringSocial提供了一个机制叫SocialUserDetailsService.需要满足loadUserByUserId,传进来的是找到的UserId.要做到是找到UserDetails的实现并返回

记得将这个类移动到core项目中,而不是在browser项目中,因为都要用.

3.6 配置

比如AppId与Appsecret都要在此进行配置

新建类QQProperties继承SocialProperties

新建SocialProperties

将SocialProperties加入Security的配置中

这三个配置项将要用在QQConnectionFactory的构造函数中.

新建QQAutoConfig

因为我这里配的是一个连接工厂,只有在配置里配置了AppId与AppSecret时才希望App生效,如果系统里没有配,希望配置不生效.

当配置文件里imooc.security.social.qq.app-id被配置了,拿底下的配置才会生效.

在配置文件里进行配置

3.7 SocialFilter

在SpringSecurity中将其引入,这个配置的作用就是在当前的过滤器链上,去加一个过滤器,过滤器会拦截特定的请求,然后去引导用户去做社交登陆.

3.8 加一个QQ登陆的入口

所有/auth开头的请求都会被SocialAuthentication拦截,第二段Url是你的ProviderId.

SocialAuthenticationFilter

第四章处理QQ登陆时遇到的问题

4.1 redirect url is illegal

4.1.1 域名问题

在之前的第三步,返回Client并携带授权码,返回的Client的地址就是就是现在的redirect地址,地址是如何确定的呢,就是我们在QQ互联上注册时要填写一个回调域,回调域只要配置一个域名就可以了.

我们现在的回调域是下图,我们现在的回调域是有问题的,回调域只要填写域名就可以了,比如365.com,我们传过去的uri是下图,我们访问的地址与服务器跳转回来的地址都应该是登陆时填写的地址.即/auth/qq,那我们现在的uri是localhost,实际回调的是365.com,我们现在要做的就是让redirect参数和rederect地址保持一致.

现在我们将365.com映射到了本机地址,但是它访问的是80端口,因为安全的原因,80端口被禁用了,所有访问80端口的都会跳到9090端口,所以在application.properties中做如下配置.

结果就是当访问www.pinzhi365.com,就会访问本机的localhost:9090端口

4.1.2 地址问题

现在我们的地址是/auth/qq,如何改变呢?

我们之前配过SpringSocialConfigure,并将它注了进去

打开SpringSocialConfigure,发现在其中new了SocialAuthenticationFilter,并把过滤器加到了过滤器链上,可以看到在往过滤器链上加之前执行了postProcess方法

所以我们要做的是继承SpringSocialConfigure并实现自己的postProcess方法.

书写ImoocSpringSocialConfigure

这样我们将/auth变成了可配置的.

修改前端

这样我们访问的地址就是365.com/qqLogin/callback.do与回调地址相同了.

4.2 给请求做授权

4.2.1 第三方登陆流程

首先回顾一下大概的流程

过滤器去拦截请求,将信息包装到Authentication实现中,然后传递给AuthenticationManager,Manager根据其管理的实现不同挑一个provider来处理传进来的校验信息,在处理的过程中其会调用我们书写的SocialUserDetailsService接口的实现来获取用户的信息,将用户的信息封装到SocialUserDetails接口的实现中,进行检查和校验,如果都通过了那么会把用户信息放到我们之前封装的Authentication中,然后把Authentication标记成经过认证的.

在SpringSocial提供的第三方登陆中涉及了一些特殊的东西,比如说过滤器在封装Authentication给Manager的时候,用到的一个接口叫做SocialAuthenticationService,此Service将执行整个OAuth的流程,在执行的过程中会调用我们的ConnectionFactory,ConnectionFactory会拿到ServiceProvider,ServiceProvider中有一个OAuth2Operations,它会帮助SpringSocial完成整个流程,完成流程后会拿到服务提供商的信息,服务提供商的信息会封装到Connection中,Connection会被封装到SocialAuthenticationToken,Token会被交由Manager中,然后被交由SocialAuthenticationProvider来处理此Token,provider在处理时会根据传过来的connetion里的服务提供商的信息,使用我们jdbcUsersConnectionRepository去从数据库中查询一个UserId出来,查找到UserId再调用我们的SocialUserDetialsService查出来我们的SocialUserDetails,最后再把SocialUserDetails放在SocialAuthenticationToken中,标记为已经过身份认证,放在SecurityContext里,最终放在session里.

蓝色的都是系统实现的,橘色的是我们自己写的,