《Oauth2实战》四种许可模式比较

1. 资源拥有者许可机制        用户输入用户名和密码去获取token

这种许可机制就是我们平时最常见的登录页面，输入用户名和密码或者手机号验证码。密码虽然被讨厌，但是有时候也不得不去使用密码。一个系统可不可以只用微信或者支付宝登录，不用手机号和密码呢？原理上是可以的，但是系统只有用户的微信id等信息，没有手机号或者密码等信息。如果微信不让授权了呢？用户没有办法登录了。而且这样让用户不去输入手机号，只能变成系统提示绑定手机号的形式，手机号非必填，如果有事情怎么联系用户呢。所以授权码更多时候只能是登录的一种补充，不能成为替代。用户需要先注册系统账号，然后绑定微信，然后才使用微信登录。

特点：

      需要用户在客户端输入密码、用户授权、没有授权码

2.授权码许可模式

之前我理解的授权码许可仅仅在第三方登录使用，本质上是我们要使用微信的信息去让这个用户登录我们的系统。但是我们又不能让用户在我们系统输入他自己微信的账号密码，所以有了授权码模式。微信提供一个授权中心，用户在微信授权中心输入自己微信的账号密码登录之后，同意授权。最后微信给这个用户的用户信息，我们根据微信的用户ID查找到我们系统用户的信息，然后登录。

授权码模式的本质是什么？就是我们要获取别的系统的用户资源，只要经过用户授权就可以获取了。整个授权码流程只是为了保证用户隐私信息的安全而已。我们要获取用户信息就需要token，但是token给到前端不安全，给到后台也不行。因为给到后台如果客户端没有后台呢？有后台的话那后台怎么把用户信息最后给前端呢？使用websocket就太局限了，不符合主流的前端调用后台的通信方式，而是使用双工通道通信。因此使用一个中间值code，这个code有很多限制，code暴露在前端也不会导致token泄露。

特点：

       需要用户授权、不用用户在客户端输入密码

3.隐式许可模式

这种许可模式是用户授权之后，直接把token发给前端，中间没有授权码。

这种应用于客户端只有前端页面，没有后台的场景。因为没有后台，只能用前端接收token了，也是因为没有后台，用code值目的是为了让token出现在后台而不是前端，客户端没有后台那么code值也就没用了。

特点：

        需要用户授权、没有code、直接生成token

4.客户端凭据许可模式

这种模式是客户端只代表自己访问资源，不需要经过用户的授权。那么局限性也很明显，不能访问用户的私有信息，因为这种流程根本没用用户授权这一步，用户没有授权就不能访问自己的资源。

这种模式只能访问另一个系统公开的非用户本人的信息。

特点：

       不需要用户授权、没有code