資訊專欄INFORMATION COLUMN
摘要：總結(jié)總結(jié)歸根結(jié)底并不是要推翻，而是根據(jù)其安全最佳實(shí)踐移除不安全的授權(quán)流程并且對(duì)擴(kuò)展協(xié)議進(jìn)行整合讓原本復(fù)雜如迷宮的規(guī)范成為更易用，更安全的授權(quán)規(guī)范。
2010年, OAuth 授權(quán)規(guī)范 1.0 (rfc 5849) 版本發(fā)布, 2年后, 更簡單易用的 OAuth 2.0 規(guī)范發(fā)布（rfc 6749）, 這也是大家最熟悉并且在互聯(lián)網(wǎng)上使用最廣泛的版本, 在2012年的時(shí)候, iPhone 5 是全新的, 微軟最新的瀏覽器還是 IE9, 單頁面應(yīng)用在當(dāng)時(shí)還被稱作 "Ajax 應(yīng)用", CORS（跨域資源共享）還不是一個(gè)W3C標(biāo)準(zhǔn)。
到現(xiàn)在, 網(wǎng)絡(luò)和移動(dòng)領(lǐng)域發(fā)生了巨大的變化, 當(dāng)時(shí)發(fā)布的授權(quán)協(xié)議標(biāo)準(zhǔn)已經(jīng)遠(yuǎn)遠(yuǎn)不能滿足現(xiàn)在的場景和需求, 為了應(yīng)對(duì)這種不斷變化的局面, OAuth 社區(qū)多年來一直在修補(bǔ)和擴(kuò)展 OAuth 規(guī)范, OAuth 的格局也不斷擴(kuò)大, 越來越多的圍繞 OAuth 2.0 core 的擴(kuò)展授權(quán)規(guī)范出現(xiàn), 也讓 OAuth 2.0 整體看起來就像一個(gè)迷宮一樣。
在 OAuth 2.0 核心規(guī)范 (RFC 6749)中, 定義了四種授權(quán)類型：授權(quán)碼、隱式、密碼和客戶端憑據(jù), 如下:
相信大家都很熟悉, 在 OAuth 2.0 中,最安全也是使用最普遍的就是授權(quán)碼模式, 而對(duì)于本地應(yīng)用，移動(dòng)應(yīng)用來說, 通常會(huì)使用隱式和密碼授權(quán), 這兩種本身就是不安全的, 因?yàn)檫@些屬于公開的客戶端, 本身沒有能力保護(hù)客戶端機(jī)密, 但是當(dāng)時(shí)并沒有其它好的方案。
為了解決 OAuth 2.0 對(duì)公開客戶端的授權(quán)安全問題, PKCE （RFC 6379）協(xié)議應(yīng)運(yùn)而生, 全稱是 Proof Key for Code Exchange，PKCE 的原理是, 對(duì)于公共的客戶端, 如果不能使用客戶端秘鑰（client_secret）, 那客戶端就提供一個(gè)自創(chuàng)建的證明 (code_verifier) 給授權(quán)服務(wù)器，其中使用了加密算法, 授權(quán)服務(wù)器通過它來驗(yàn)證客戶端。
后來，"OAuth 2.0 for Native Apps"（RFC 8252）規(guī)范發(fā)布，推薦原生應(yīng)用也使用授權(quán)碼 + PKCE。
隨著技術(shù)不斷地發(fā)展, 出現(xiàn)了設(shè)備授權(quán)的場景, 這里設(shè)備指智能電視，打印機(jī)等, 和傳統(tǒng)的PC或者手機(jī)不同, 這種設(shè)備是缺少瀏覽器或者鍵盤的,那 OAuth 2.0 常規(guī)的授權(quán)模式肯定是不能滿足的, 于是就出現(xiàn)了設(shè)備授權(quán)(Device Grant) 。
在 OAuth 2.0 安全最佳實(shí)踐（Security BCP）中, 棄用了隱式和密碼授權(quán)，并且推薦所有的客戶端都應(yīng)該使用 Authorization Code + PKCE 的組合。
最終, 調(diào)整后的 OAuth 授權(quán)模式會(huì)更加精簡, 轉(zhuǎn)換成下面三種, 這也是 OAuth 2.1 的思想, 參考安全最佳實(shí)踐(BCP)，取其精華, 去其糟粕。
歸根結(jié)底, OAuth 2.1 并不是要推翻 OAuth 2.0，而是根據(jù)其安全最佳實(shí)踐(BCP), 移除不安全的授權(quán)流程, 并且對(duì)擴(kuò)展協(xié)議進(jìn)行整合, 讓原本復(fù)雜如迷宮的 OAuth 2.0 規(guī)范成為更易用，更安全的授權(quán)規(guī)范。
The OAuth 1.0 Protocol
The OAuth 2.0 Authorization Framework
The OAuth 2.1 Authorization Framework draft-ietf-oauth-v2-1-04
Its Time for OAuth 2.1
OAuth 2.0 for Native Apps
OAuth 2.0 Device Authorization Grant
Proof Key for Code Exchange by OAuth Public Clients
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/124545.html
摘要：使用時(shí)不應(yīng)該通過傳遞使用時(shí)不應(yīng)該通過傳遞根據(jù)安全最佳實(shí)踐章節(jié)在使用時(shí)您不應(yīng)該把放到中第一瀏覽器地址欄本來就是暴露的第二可以查看瀏覽記錄，找到。OAuth 2.1 是 OAuth 2.0 的下一個(gè)版本, OAuth 2.1 根據(jù)最佳安全實(shí)踐(BCP), 目前是第18個(gè)版本，對(duì) OAuth 2.0 協(xié)議進(jìn)行整合和精簡, 移除不安全的授權(quán)流程, 并發(fā)布了 OAuth 2.1 規(guī)范草案, 下面列出了...
摘要：閉包利用的，其實(shí)就是作用域嵌套情況下，內(nèi)部作用域可以訪問外部作用域這一特性。之所以要將閉包和垃圾回收策略聯(lián)系在一起，是因?yàn)檫@涉及到閉包的一些重要特性，如變量暫時(shí)存儲(chǔ)和內(nèi)存泄漏。因?yàn)槟涿瘮?shù)回調(diào)的閉包實(shí)際引用的是變量，而非變量的值。 本文旨在總結(jié)在js學(xué)習(xí)過程中，對(duì)閉包的思考，理解，以及一些反思，如有不足，還請(qǐng)大家指教 閉包---closure 閉包是js中比較特殊的一個(gè)概念，其特殊之處...
摘要：框架加冕時(shí)代年橫空出世的前端框架的模塊機(jī)制的模塊機(jī)制相比老王老李的解決方案上增強(qiáng)了模塊的約束性，和幫助開發(fā)者劃分模塊外，最重要的是解決了模塊的運(yùn)行時(shí)管理問題模塊的初始化順序問題和依賴的模塊自動(dòng)初始化問題。 前端框架工程化之路 人類的發(fā)展動(dòng)力源于一個(gè)懶字，就如現(xiàn)在的大前端正是史前那群懶而聰明的切圖仔進(jìn)了軟件工程的施工現(xiàn)場，懷揣著更少代碼、更少溝通、更少錯(cuò)誤、更少維護(hù)的夢想奔襲而來。從框架...
閱讀 736·2023-04-25 19:43
閱讀 3981·2021-11-30 14:52
閱讀 3807·2021-11-30 14:52
閱讀 3871·2021-11-29 11:00
閱讀 3802·2021-11-29 11:00
閱讀 3904·2021-11-29 11:00
閱讀 3580·2021-11-29 11:00
閱讀 6184·2021-11-29 11:00
