前言：先出個簡單的構思流程，後面再詳細解釋具體實際中的流程，真實的流程比較複雜，所以先看概念再理解具體流程。
OAuth協議的出現：隨着互聯網的發展出現了很多應用：各種網站，遊戲，app.....這些應用都需要賬號去登陸，剛開始我們只有玩一個遊戲一個聊天應用，但隨着時代的發展出現了更多的應用：微信，抖音，王者榮耀，LOL，甚至愛奇藝，騰訊視頻....這些看電影聽歌的app也需要賬號登陸了，還記得以前看電影聽歌不要錢，而現在，萬惡的資本家。扯遠了，不好意思~~~~~~~~~~
在這麼多應用蜂擁而至的當下我們不可能給他們每個設立一個賬號，儘可能的使用一個賬號就可以登陸所有的應用，這才適合當下的我們，於是出現大多數應用都能支持：微信，QQ，以及手機驗證碼登陸，已經很少有賬號密碼登陸了。
而這些第三方(抖音，王者榮耀，愛奇藝.....)使用微信，QQ，短信驗證碼登陸，就是用OAuth協議實現的。
OAuth 2.0概念：
第一個出場的是：資源服務器。就像微信的資源服務器，上面存儲着你的好友列表，個人信息.....
接着我們使用第三發登陸，最簡單的登陸方式：
這種登陸方式最直接，第三方直接請求獲取用戶數據即可登陸。
問題：但這樣要是遭到惡意攻擊那用戶的數據就直接泄漏。
解決方案：第三方(抖音，愛奇藝....)需要一個權限才能獲取數據，這個權限在OAuth2.0中叫：access_token（令牌），這個asscess_token肯定不能用第三方應用程序產生，否則惡意攻擊程序也就能自己產生了，所以我們需要一個第三發專門生成access_token的服務器，我們稱之爲：認證服務器(Autherization server),於是就演變成下面這樣：
我們可以看到現在的流程是：第三方先是請求認證服務器獲得access_token（令牌），之後使用得到的access_token（令牌）來請求資源服務器，最終拿到資源。
流程看着問題不大但任然有問題：
問題：認證服務器產生access_token，請求者可以隨便獲取，並且沒有什麼限制，這樣好像惡意程序任然可以通過認證服務器拿到access_token，所以問題還是沒解決。
最終解決方案：認證服務器應該得到資源擁有者的同意再產生access_token纔行，這樣資源擁有者同意過後第三方纔能登陸，這樣就解決問題了，當惡意程序想要獲取access_token時資源擁有者不同意那它就沒辦法攻擊你了，從而也保證了你資源的安全，於是最終OAuth2.0就採用了以下流程：
到目前爲止OAuth2.0的基本理念就講清楚了，之所以一步一步來是想我們要理解他每個模塊存在的意義，正真的流程比這個要複雜一些，但理念相同，我們後面在講。
問題1：去掉認證服務器，第三發直接請求資源擁有者獲得access_token不行嗎？
首先我們要明白：資源擁有者是終端(我們的手機，電腦...),這些設備屬於客戶端，若是使用這些設備生成access_token那麼惡意程序也就能生成access_token了，因爲access_token的算法和數據都暴露給惡意程序了，因此需要服務器去生成，而這個服務器就是認證服務器Authorization server。
問題2：將認證業務與資源放到同一個服務器，然後先請求認證業務獲得access_token後，直接獲得對應的資源返回給第三方行不行？第三方 -> 認證請求用戶返回肯定後直接將資源 -> 第三方，這樣一次請求即可，不用那麼複雜。
這樣做可以，我們同樣能獲得想要的結果。
但這樣做的問題是：認證和資源耦合在一起，業務混亂，不好擴展需要維護額外的數據，如認證請求的數據要存起來等用戶響應後在取出來，類似這些數據維護工作要做很多，這樣第一：開發量大，業務變的複雜，運行壓力大多出很多沒必要的開銷，總之弊大於利。