oauth 2.0 —— 開放授權協議，對應的規範檔案rfc-6749早在2023年便成形，所以這並不是乙個新的技術（你問我為啥研究這個，我也想吟一首詩啊。。。組織上就是這樣決定的），但由於其必不可少的價值，在今天的網路上已經得到了廣泛的應用。
oauth2.0認證是要在不同的應用之間打通互信，互信的目的是為了實現一定程度上的使用者資料分享，沒資料的一方到有資料的一方拿資料，並且在時間尺度上，資料的分享是受控的。
在這些場景裡都涉及三方：使用者、沒資料的應用、有資料的應用（授權、資源）。oauth2.0規範就規定了三方如何互動，完成許可權的授予，獲取資料的過程。整體邏輯過程如下圖
整個授權框架中包含了4種授權模式：
在詳述4種模式之前，首先需要注意，第三方應用需要先到資源持有應用處註冊身份，提交**uri，註冊成功後，得到標識身份的 client id 和 client secret。資源持有者也可以趁這個階段對第三方應用進行安全審核。
client type， 根據客戶端與授權伺服器進行安全認證的能力，分為 confidential（機密客戶端）和 public（公開客戶端）。授權碼模式是四種模式中最嚴密的，主要用於web應用，我們來看看整體邏輯圖client id和client secret，應用的身份標識。
registered redirect uris，**位址，後面會用到。
下面我按圖上的順序一步步說明。
我在瀏覽器上開啟了leetcode網頁，並且發現可以用github賬戶來登入，於是，我點選了章魚標誌。這個時候，就被leetcode導向了github的認證頁面，並且攜帶了幾個必要引數。
client id，表明第三方應用自己的身份，即這個請求是從leetcode過來的。現在開啟了github的認證頁面（如果沒有事先登入，github會要求我先登入github賬號），github頁面提示是否授權給leetcode，點選是，則進入下一步；否則，流程結束。scope，表明要請求哪些使用者資訊，使用者名稱、密碼、郵箱、頭像……
redirect uri，應用註冊時填入的**uri之一，授權伺服器會檢查，必須嚴格匹配。
state，乙個不容意被猜到的隨機數，用於第3步確認收到的code是自己請求的，避免 csrf 攻擊。
github呼叫**uri（這個uri就是最初註冊時提交的uri之一），傳回授權碼，把state也傳回。這時，授權碼就到了第三方應用的後台伺服器。這一步之後的互動，在瀏覽器上就看不到了，由兩個應用的後台伺服器完成。
authorization code，授權碼，乙個臨時的隨機串。拿到code，並比對了state後，leetcode伺服器就拿著這個code去換訪問令牌。state，第1步傳過來的state。
client id & client secret，表明自己的身份。授權伺服器認證了客戶端身份，並檢查**位址通過後，呼叫**uri回傳訪問令牌。redirect uri，獲取授權碼時提交的**位址，授權伺服器會檢查是不是一致。
authorization code，前面拿到的授權碼。
token type，值為 bearer token。現在leetcode可以拿著令牌去github獲取我的賬戶資訊了，從瀏覽器上看，我順利登入了leetcode。access token，訪問令牌，訪問資源的憑據。
scope，許可權範圍。
expires in，令牌有效時間，單位秒。
refresh token，可選引數，使用者更新訪問令牌。
回過頭來看一下，為什麼先發乙個授權碼，不直接發訪問令牌？
因為直接發令牌，那麼到達使用者瀏覽器的就是令牌。而拿著令牌去訪問資源是不需要認證的（別問為什麼，就是這樣的設計和用法）。如果本地環境不可信，那麼讓第三方應用伺服器和資源伺服器去互動，完成code到token的轉換是更安全的選擇。
即使authorization code被另乙個應用竊取，並且該應用在授權伺服器上合法，也不能使用這個授權碼，因為授權伺服器會檢查帶著授權碼過來換token的應用是不是最初申請該授權碼的應用。
而且，授權碼只能被使用一次，當在本地被竊取了以後，如果你使用一次code，攻擊者使用一次code，不管誰先誰後，第二次使用code將導致授權伺服器終止該code及已下發的token的有效性。
隱式許可模式和授權碼模式最大的不同就是沒有授權碼互動這一環節，它主要用於依附於瀏覽器的駐於使用者側的應用，如j**ascript應用。
還是從圖說起
和授權碼模式一樣。
和授權碼模式一樣。
使用者授權通過後，呼叫**uri，直接就傳回訪問令牌。
redirect uri，指向第三方應用的資源伺服器。訪問第三方應用的資源伺服器，請求從fragment引數中提取訪問令牌的指令碼，由於http規範，請求中不會攜帶fragment部分。fragment with access token, etc.，在uri的fragment部分（即#後的部分）攜帶訪問令牌等引數，只會被留在瀏覽器本地，裡面包含了和授權碼模式第5步中相同引數。
返回解析指令碼，並提取出訪問令牌。
拿著訪問令牌去獲取資源。
這裡看到4、5的時候，困惑了很久，為什麼要特地去第三方應用的伺服器上取解析指令碼，有什麼安全考量。so上某個5k聲望的仁兄的回答是：沒看出什麼考慮，只是在本地放指令碼和去伺服器取指令碼中選了一種方式。我看，是不是因為反正都會用到 redirect uri，就順便取個指令碼，不然糟蹋了這一來一回。最後訪問令牌留在了駐使用者側的應用裡。考慮到這種模式不嚴瑾，行業最佳實踐建議採用授權碼模式或pkce模式。
密碼模式就是使用者把使用者名稱和密碼都放心地給到第三方應用（如山一般厚重的信任），第三方應用以使用者的名字去認證並獲取資源。規範中規定了應用不應該儲存使用者輸入的使用者名稱和密碼。此種模式多見於資源伺服器自家的應用。
第三方應用證明自己的身份，以自己的身份去獲取一些公共的資源。這種模式我就不細解釋了，引數用途和前面的一致。
基本就是這樣了，下次再講講 pkce、device code。
如理解有誤，歡迎各位老鐵拍磚。
參考：
OAuth2 0認證授權
授權碼模式 authorization code 是功能最完整 流程最嚴密的授權模式。它的特點就是通過客戶端的後台伺服器，與 服務提供商 的認證伺服器進行互動。client id x client secret x response type 表示授權型別，必選項，此處的值固定為 code clie...
OAuth2 0認證和授權原理
一 什麼是oauth協議 oauth 開放授權 是乙個開放標準。允許第三方 在使用者授權的前提下訪問在使用者在服務商那裡儲存的各種資訊。而這種授權無需將使用者提供使用者名稱和密碼提供給該第三方 oauth允許使用者提供乙個令牌給第三方 乙個令牌對應乙個特定的第三方 同時該令牌只能在特定的時間內訪問特...
OAuth2 0認證和授權原理
什麼是oauth授權？一 什麼是oauth協議 oauth 開放授權 是乙個開放標準。允許第三方 在使用者授權的前提下訪問在使用者在服務商那裡儲存的各種資訊。而這種授權無需將使用者提供使用者名稱和密碼提供給該第三方 oauth允許使用者提供乙個令牌給第三方 乙個令牌對應乙個特定的第三方 同時該令牌只...