关于oauth 2.0和单点登录

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

oauth 2.0协议中有四个角色，资源拥有者、客户端、授权服务器、受保护资源/资源服务器。
第三方应用接入微信登录的例子中，用户就是资源拥有者，第三方应用是客户端，用户的微信账号信息是受保护资源、微信开放平台是授权服务器。由于第三方应用获取到令牌之后，也会使用这个令牌去访问自己的后端API，所以第三方应用其实也属于资源服务器。

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

利用oauth 2.0也可以实现单点登录。
例如A系统和B系统利用了oauth 2.0实现单点登录，当用户登录了A系统之后，就不需要登录B系统了。完整流程为：用户首次访问A系统，去到认证中心进行登录认证，认证成功后获取到令牌；然后B系统使用这个令牌去认证中心校验后获取到A系统登录的用户信息，就可以直接访问B系统。在这个流程中，A系统作为客户端角色，去到认证中心申请令牌；而A系统登录的用户信息就属于受保护资源；B系统想要获取到A系统登录的用户信息，利用这个用户信息来直接访问B系统。这就实现了单点登录。
对于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进行多个子系统间的转发。