关于oauth 2.0和单点登录

什么是oauth 2.0，在实际场景中解决了什么问题？

oauth 2.0是开放授权协议，核心思想是授权第三方应用访问用户的受保护资源，并且是以令牌的方式进行访问而不是用户名和密码，保证了安全性；例如第三方应用接入微信登录，就是利用了oauth 2.0来实现的。如果没有接入微信登录，那用户使用多个应用系统都需要分别注册账号，用户体验不好，而接入微信登录之后，对于用户而言，其实就是使用一个微信账号登录多个应用系统。底层的实现原理是：当第三方应用想要使用微信登录时，目的就是获取到用户的微信账号信息，例如用户名、头像、昵称等（用户的微信账号信息其实也是微信开放平台上的一个API），将这些信息作为自己平台的账号信息，自动为用户注册平台账号，用户每次只需要通过微信进行登录即可；但是用户不会直接把微信账号密码给第三方应用，这样做比较危险，容易越权；而是给第三方应用进行授权，利用令牌代替账号密码去访问用户的微信账号信息。整个流程就是利用了oauth 2.0这个授权协议来实现的。

注意：当第三方应用成功访问到微信开放平台上获取用户微信信息的API时，即已经获取了用户的微信账号信息，接下来的操作不属于oauth 2.0流程中的，属于第三方应用本身自己的处理，例如先在自己的系统中看看是否已存在这个用户，不存在自动注册，存在则完成认证流程，例如生成session或者token返回给浏览器，浏览器后续携带sessionId或者token访问第三方应用自己的资源时，第三方应用后台进行校验，校验成功返回对应的资源。这个流程已经没有微信开放平台参与了，属于是第三方应用自己的流程。

再举一个小兔打单软件的例子，假如小明在京东上面开了一个店铺，日常运营中需要将订单打印出来以便给用户发货，以前是手工操作，后来发现有个叫“小兔”的第三方软件，可以帮助小明打印京东上的订单。小兔软件要进行打单操作时，就需要访问小明在京东店铺上的订单；京东商城提供了开放平台，小兔通过京东商家开放平台的 API 就能访问到用户的订单数据。具体流程是，小兔软件点击打单操作时，相当于要请求京东开放平台获取用户订单数据的API，这需要用户进行授权，那么小兔软件会引导小明去到京东开放平台进行认证，然后授权小兔软件访问这个API，小明同意之后京东开放平台发放令牌，小兔软件带着这个令牌再去调用京东开放平台这个API，京东开放平台校验令牌合法后，返回用户的订单数据给小兔软件，其实就是把小明的受保护资源-用户的订单数据返回给小兔软件，整个流程就是利用了oauth 2.0这个授权协议来实现的。

在这两个例子中，微信开放平台、京东开放平台不仅仅是一个授权服务器，负责令牌发放、令牌校验；而且还维护了很多API，这些API就是所谓的受保护资源，例如获取用户的微信账号信息是一个API，获取用户的订单数据也是一个API；当用户携带令牌来这些开放平台进行校验时，校验通过后就会返回这些API的数据，即将这些受保护资源返回给第三方软件。

oauth 2.0协议中有四个角色，资源拥有者、客户端、授权服务器、受保护资源。
第三方应用接入微信登录的例子中，用户就是资源拥有者，第三方应用是客户端，用户的微信账号信息是受保护资源、微信开放平台是授权服务器。
小兔打单的例子中，小明就是资源拥有者，小兔软件是客户端，用户的订单数据是受保护资源、京东开放平台是授权服务器。

oauth 2.0和单点登录有什么区别？

单点登录和oauth 2.0本质上就不是同一个东西。
单点登录指的是：多个应用的系统中，用户只需要登录一次就可以访问其他应用子系统，不需要重复登录多次。例如用户只要登录了百度的官网，那么对于百度百科、百度知道、百度贴吧等网站都是处于登录状态。
单点登录是一种思想，对应有多种实现方案，例如CAS框架就可以用于实现单点登录。

利用oauth 2.0也可以实现单点登录。我们通常会基于oauth 2.0协议搭建一个认证中心（其实也是授权服务器），然后还需要分别搭建客户端、资源服务器；如果对应的子系统会向认证中心申请令牌，那么就是客户端角色，如果对应的子系统是拿着已经申请的令牌去向认证中心校验，返回用户信息，那么就是资源服务器角色。

例如A系统和B系统利用了oauth 2.0实现单点登录，当用户登录了A系统之后，就不需要登录B系统了。完整流程为：用户首次访问A系统，去到认证中心进行登录认证，认证成功后获取到令牌；然后B系统使用这个令牌去认证中心校验后获取到A系统登录的用户信息，就可以直接访问B系统。在这个流程中，A系统作为客户端角色，去到认证中心申请令牌；而A系统登录的用户信息就属于受保护资源；B系统想要获取到A系统登录的用户信息，利用这个用户信息来直接访问B系统。这就实现了单点登录。这个流程也是使用到了oauth 2.0的思想。
对于B系统来说，想要获取到A系统登录的用户信息，并不是直接使用A系统的账号密码进行登录，而是利用A系统授权后拿到的令牌，这就是oauth 2.0协议。
用户访问B系统，需要依靠A系统登录授权后获取到的令牌，所以B系统是资源服务器角色；另外，A系统也会使用这个令牌去访问自己的后端API，所以A系统其实也属于资源服务器。

如果A系统和B系统任意一方都可以去到认证中心进行登录，获取令牌，给到对方进行访问，那么A系统和B系统都可以属于oauth 2.0协议中的客户端角色；如果A系统和B系统只有一方能够去认证中心登录，另一方就等着接收令牌，那么能去到认证中心登录的子系统才属于oauth 2.0协议中的客户端角色，另一方严格上来讲其实不属于客户端角色，因为客户端角色的任务就是去认证中心登录，并获取到令牌。那么它的角色我们可以认定为资源服务器。

在前后端分离的架构中，利用oauth 2.0实现单点登录可以分两种情形，有门户系统和没有门户系统。

如果我们的应用具有门户系统，用户要访问A系统或B系统都只能先登录门户，获取到令牌后再使用这个令牌访问A系统和B系统，这种情形中，门户系统其实就是oauth 2.0中的客户端角色，而A系统和B系统都属于资源服务器。

门户系统还有另一种情况，假设用户要访问我们的系统之前，需要通过登录A系统，B系统只能依靠A系统登录后通过按钮进行跳转。那其实A系统的前端就属于客户端角色，A系统的后端服务和B系统的后端服务都属于资源服务器。

如果没有门户系统的情形下，A系统和B系统都有自己的前端登录界面，那其实A系统和B系统是割裂开的；例如淘宝和天猫，这是两个独立的系统，有各自的登录界面，用户登录淘宝之后，就不需要再登录天猫了。这种情形，淘宝和天猫的前端页面属于客户端角色，都可以向授权服务器申请令牌，而淘宝和天猫的后端服务就属于资源服务器。

在企业实际应用中，需要进行单点登录的多个子系统都是有紧密关联的，因此通常会引进门户系统或者将某个子系统作为门户，然后利用nginx进行多个子系统间的转发。