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流程就結束了。