1. 隱式授權模式（implicit grant）
第一步：使用者訪問頁面時，重定向到認證伺服器。
第二步：認證伺服器給使用者乙個認證頁面，等待使用者授權。
第三步：使用者授權，認證伺服器想應用頁面返回token
第四步：驗證token，訪問真正的資源頁面
授權碼授權模式（authorization code grant）
第一步：使用者訪問頁面
第二步：訪問的頁面將請求重定向到認證伺服器
第三步：認證伺服器向使用者展示授權頁面，等待使用者授權
第四步：使用者授權，認證伺服器生成乙個code和帶上client_id傳送給應用伺服器
然後，應用伺服器拿到code，並用client_id去後台查詢對應的client_secret
第五步：將code、client_id、client_secret傳給認證伺服器換取access_token和
refresh_token
第六步：將access_token和refresh_token傳給應用伺服器
第七步：驗證token，訪問真正的資源頁面
密碼模式（resource owner password credentials grant）
缺點：侷限性，認證伺服器和應用方必須有超高的信賴。(比如親兄弟？)
應用場景：自家公司搭建的認證伺服器
客戶端憑證模式（client credentials grant）
第一步：使用者訪問應用客戶端
第二步：通過客戶端定義的驗證方法，拿到token，無需授權
第三步：訪問資源伺服器a
第四步：拿到一次token就可以暢通無阻的訪問其他的資源頁面。
這是一種最簡單的模式，只要client請求，我們就將accesstoken傳送給它。這種模式是最方便但最不安全的模式。因此這就要求我們對client完全的信任，而client本身也是安全的。
因此這種模式一般用來提供給我們完全信任的伺服器端服務。在這個過程中不需要使用者的參與。
個人理解，如有錯誤，請幫我指出下，謝謝。
OAuth2四種模式
二 授權碼授權模式 authorization code grant 三 密碼模式 resource owner password credentials grant 四 客戶端憑證模式 client credentials grant 第一步 使用者訪問頁面時，重定向到認證伺服器。第二步 認證伺服...
OAuth2 模式介紹
1.憑證 客戶端 模式 allowedgranttypes granttypes.clientcredentials 應用場景 客戶端 服務與服務之間的互動訪問資源，token代表客戶端的請求，而不是使用者，攜帶客戶端註冊時候的貧據進行認證，獲取token,使用過程 會向token endpoint...
OAuth2協議簡介
例如我在qq上有很多的，分別儲存在不同的資料夾中，現在有乙個第三方登入需要訪問我的其中某乙個檔案時ru我需要怎麼做呢？如果我直接將我qq的賬號 密碼直接給第三方應用，那它就可以訪問我的全部，但是有的我是不想給他的！而且如果我只是想讓他訪問一段時間，過了這個時間之後，我就不想讓第三方訪問了，這個時候那...