1、 Oauth2.0 解决了一个什么样的问题？
在此之前，我们在登陆每个应用时，采用账户和密码的模式。大家六亲不认，只认密码。同样，用户的应用与应用之间，也往往是这样的，如果应用A你要访问我应用B，那你必须要有客户在我应用B中的账户和密码。
这个优点是，简单，粗暴。缺点是，应用B的客户隐私都泄露了，谁都担心；另外，互相要记这么多账户和密码，特别是密码，谁受得了。特别是老同志。
有没有一个通用的应用（类似于QQ，微信，github），可以用来登陆其它的应用(比如csdn,知乎,163邮箱等)？
Oauth2.0就是解决这个问题的。
2、模式与区别
我们以QQ账户登陆csdn来举例：
在Oauth2.0模式下，【授权方和资源方】
QQ应用账户（授权方）去登陆csdn（第三方），此时是csdn访问QQ应用【QQ是资源方，不要搞反了】，访问QQ的用户的信息，以及其它授权的信息范围；在原来的模式下，需要QQ应用的账户和密码来验证；此时QQ不需要给密码，而是发token，这样，csdn可以用QQ方发的token也可以访问QQ.
相当于，你去银行取钱，你出示国家发的身份证，就可以；
而原来的模式是，csdn请你登陆者出示你在csdn注册的账户和密码，其它的什么身不身份证的，不管。
具体的模式是：
在上面，用几个角色：
比如资源所有方（resource owner）：用户
第三方应用：client Application ；在这里指的是csdn
资源服务器：resource server ; 指的是QQ
认证服务器：authorization server
在现实中，资源服务器与认证服务器往往为一体。比如QQ 。账户服务器（也就是资源服务器）和认证服务器往往就都由QQ方安排。
容易混同：
需要注明的是：当QQ去登陆CSDN时，是CSDN去访问和索要（get\post\put等）QQ的数据和信息，不是QQ去访问CSDN的信息。这个和直觉好象不符。这主要与展示产生的错觉有关。
总结一下：
授权服务器看到用户的授权发code；
授权服务器经验证程序后发token；
资源服务器负责给持有token的访问者，访问它的账户信息，以及其它授权信息(scope)；
3、Oauth2.0是如何工作？
Oauth2.0有四种模式，本文以授权码模式来介绍。
上一张图：【这个模式相对简化】
资料来源：https://zhuanlan.zhihu.com/p/46573571
从QQ账户登陆doubian的过程，比较清楚地介绍了这么几个流程：
用户登陆QQ->
QQ认证中心发出授权码code->
用户把获得的code给doubian ->
doubian把code给QQ认证中心->
QQ认证中心把token给doubian ->
doubian 带着token就可以访问QQ了【用户信息及其它信息】
4、为什么要有code呢？
code本身就临时的，比如，很多应用设置10分钟过期。即使code被人抢走，后用login时还是会产生code，会把前面的产生的token覆盖。
5、需要什么验证程序才发token？–签名验证算法
这个涉及到移动应用开发中AppID、AppKey、AppSecret。
具体参见：https://www.cn-shenliang.com/newsinfo/360153.html
其中， AppID：应用的唯一标识，“应用的身份证” 【这个我认为应是QQ认证这个应用的唯一编号，应是QQ方发的，待确认】
AppKey：公匙（相当于账号）【这个是应是开发人员通过算法生成的，也可以通过特定平台比如微信、QQ等平台的工具生成，这个是给QQ方解签用的】
AppSecret：私匙（相当于密码，与AppKey是一对的，类似RSA的一对key）【这个是开发人员签名用的，不能暴露给其它人】
我理解： doubian
用AppSecret即私匙对相关的信息（或其摘要）进行签名，同时发布Appkey公匙，让QQ 资源服务器去解签，如果成功，证明的确是由doubian发来。解签后，才发出token.
这里用到了签名的算法。
6、为什么Oauth2.0能起到安全认证的作用？
待补充
7、https起到什么作用？
防止token以明文的方式 传输。正常的话，认证中心的token会以加密的方式。此时，支持https就是必要的。
如果全部以https传输的话，理论上code也可以不用（待确认）？
8、为什么需要url重定向？
因为h5或页面的跳转，不会自动生成，比如
当用户点击按钮同意授权后，授权服务器将生成一个用户凭证（code），此时授权服务器如何将用户凭证（code）传递给第三方应用呢？此时，就需要有重定向机制，即跳转环节。
9、token有效期多长？
正常情况下有access_token，expire_date,refresh_token三个字段。如果到期了，access_token就会失效，需要重新更新。
比如，我们在QQ上一个应用时，过了一段时间，就会要我们重新登陆。这个机制就被用上了。
参考资料：
1、http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
2、https://www.chrisyue.com/security-issue-about-oauth-2-0-you-should-know.html
3、https://zhuanlan.zhihu.com/p/46573571
4、https://zhuanlan.zhihu.com/p/20913727
其中，参考文献3的流程总结如下：
第1步. 用户授权用户身份确认后会进入下面这个页面，该页面由授权服务器提供，授权服务器会告诉用户该第三方在授权服务器中提交的相关信息（如果需要实现第三方登录功能，第三方应用需要向Github、微博等应用中提交应用的相关信息，不同服务可能会需要审核等不同的步骤），以及授权后第三方应用能够获取哪些资源。在Github中，最基础的认证可以访问用户的公共信息。如果用户同意授权，需要主动的点击【Authorize application】按钮。
第2步. 返回用户凭证（code）当用户点击按钮同意授权后，授权服务器将生成一个用户凭证（code），此时授权服务器如何将用户凭证（code）传递给第三方应用呢？当我们向授权服务器提交应用信息时，通常需要填写一个redirect_uri，当我们引导用户进入授权页面时，也会附带一个redirect_uri的信息（如Sign in to GitHub · GitHub），当授权服务器验证两个URL一致时，会通知浏览器跳转到redirect_uri，同时，在redirect_uri后附加用户凭证（code）的相关信息，此时，浏览器返回第三方应用同时携带用户凭证（code）的相关信息。授权后访问的redirect_uri如下：http://tianmaying.com/oauth/github/callback?code=9e3efa6cea739f9aaab2&state=XXX
这样，第二步返回用户凭证（code）就完成了。
授权服务器授权从这一步开始，OAuth2 的授权将有两个重大变化的发生：用户主动行为结束，用户理论上可以不需要再做任何主动的操作，作为第三方应用的我们可以在后台拿到资源服务器上的资源而对用户是不可见的，当用户的浏览器跳到下一个页面时，整个OAuth2的流程已经结束浏览器端行为结束，从OAuth2 的基本流程可以看出，接下来的流程已经不需要和用户进行交互，接下来的行为都在第三方应用与授权服务器、资源服务器之间的交互。我们知道浏览器端的行为实际上是不安全的，甚至安全凭证的传递都是通过URL直接传递的。但是由于用户凭证（code）不是那么敏感，其他攻击者拿到用户凭证（code）后依然无法获取到相应的用户资源，所以之前的行为是允许的。接下来我们看看服务器如何交互来安全的获得授权服务器授权。
第3步. 请求授权服务器授权要拿到授权服务器的授权，需要以下几个信息：client_id 标识第三方应用的id，由授权服务器（Github）在第三方应用提交时颁发给第三方应用client_secret 第三方应用和授权服务器之间的安全凭证，由授权服务器（Github）在第三方应用提交时颁发给第三方应用code 第一步中返回的用户凭证redirect_uri 第一步生成用户凭证后跳转到第二步时的地址state 由第三方应用给出的随机码
我们看到，上述信息还涉及到第三方应用的安全凭证（client_secret），因此要求OAuth要求该请求必须时POST请求，同时，还必须时HTTPS服务，以此保证获取到的验证凭证（Access Token）的安全性。
第4步. 拿到验证凭证（Access Token）当授权服务器拿到第3步中的所有信息，验证通过后，会将Access Token返回给第三方应用。
访问资源
第5步. 请求访问用户资源拿到验证凭证（Access Token）后，剩下的事情就很简单了，资源服务器会提供一系列关于用户资源的API，拿验证凭证（Access Token）访问相应的API即可，例如，在GIthub中，如果你想拿到用户信息，可以访问以下API：GET https://api.github.com/user?access_token=…
注意，此时的访问不是通过浏览器进行的，而是服务器直接发送HTTP请求，因此其安全性是可以保证的。
第6步. 返回资源如果验证凭证（Access Token）是正确的，此时资源服务器就会返回资源信息，此时整个OAuth流程就结束了。