就如同牽拉一根絲會(huì)引起整個(gè)蜘蛛網(wǎng)的伸展和重塑一樣,一項(xiàng)新技術(shù)的到來會(huì)引起經(jīng)濟(jì)中的價(jià)格和生產(chǎn)網(wǎng)絡(luò)在各行各業(yè)伸展、重塑。
OAuth 2.0 是互聯(lián)網(wǎng)應(yīng)用程序之間授權(quán)認(rèn)證的行業(yè)標(biāo)準(zhǔn)協(xié)議。它的全稱是OAuth 2.0 授權(quán)框架(The OAuth 2.0 Authorization Framework),該規(guī)范及其擴(kuò)展由互聯(lián)網(wǎng)工程任務(wù)組(IETF)的 OAuth 工作組內(nèi)開發(fā),對(duì)應(yīng)協(xié)議文檔為 RFC 6749。OAuth 2.0 協(xié)議定義了第三方應(yīng)用程序如何安全地訪問 HTTP 服務(wù)所開放的資源和功能,以實(shí)現(xiàn)應(yīng)用程序之間在功能上的互聯(lián)互通。現(xiàn)在大家都可以在微信/支付寶上交社保(以及完成其他政企事務(wù)),非常方便。傳統(tǒng)上繳納社保都應(yīng)該去社保中心,至少需要在國(guó)家社保中心app/小程序上完成,為什么在微信和支付寶上也可以?微信和支付寶是民企,并不是國(guó)企事業(yè)單位,也不是國(guó)企控股子公司,所以他們的數(shù)據(jù)必然不是互通的。在不共享數(shù)據(jù)但又想要共享部分功能的情況下,這又是如何實(shí)現(xiàn)的呢?最直接想到的方法是:把我們社保中心的賬戶和密碼直接交給微信和支付寶,讓他們幫我們登錄社保中心,然后把錢轉(zhuǎn)給社保中心。這樣做可以實(shí)現(xiàn)交社保這個(gè)目的,但是用戶信息卻面臨巨大的不安全。理論上微信/支付寶這些平臺(tái)拿到我們的賬號(hào)和密碼之后,除了交社保會(huì)不會(huì)偷偷做其他事情?如果賬號(hào)和密碼在他們平臺(tái)泄露了怎么辦?等等,這些疑問都說明顯然這不是一個(gè)很好的解決問題的方式。OAuth 授權(quán)框架就是在這樣的背景下誕生的。OAuth 1.0 的草案在 2007 年被提出,引入了授權(quán)碼和訪問令牌的機(jī)制,使得第三方應(yīng)用程序可以在不獲取用戶憑據(jù)(即賬號(hào)+密碼)的情況下訪問受保護(hù)資源,從而降低了用戶憑據(jù)泄露的風(fēng)險(xiǎn)。簡(jiǎn)單說來就是:任何需要使用用戶信息地方需要得到授權(quán);任何訪問用戶信息的請(qǐng)求需要驗(yàn)證授權(quán)。繼續(xù)上面交社保的例子(為簡(jiǎn)單說明問題暫時(shí)隱去實(shí)現(xiàn)細(xì)節(jié)):
- 微信請(qǐng)求國(guó)家社保中心,申請(qǐng)?jiān)L問小Q的社保賬戶
- 小Q選擇同意,社保中心則給小Q下發(fā)令牌(有一定時(shí)效性),小A把令牌交給微信
- 微信拿著令牌請(qǐng)求社保中心訪問小Q的社保賬戶,繳納社保
整個(gè)流程期間,微信不需要知曉用戶小Q的賬戶密碼。交社保如此,酒店入住、征信授權(quán)、登錄授權(quán)等衣食住行應(yīng)用皆如此。OAuth 2.0 在 OAuth 1.0 的基礎(chǔ)上進(jìn)行了顯著的改進(jìn),2012 年成為提案標(biāo)準(zhǔn),它解決了 OAuth 1.0 的復(fù)雜性(簡(jiǎn)化流程)、安全性(依賴 SSL/TLS 加密傳輸)問題,適應(yīng)了 Web 應(yīng)用、移動(dòng)應(yīng)用和桌面應(yīng)用等多種場(chǎng)景,成為了一個(gè)更安全、更簡(jiǎn)單、更通用的授權(quán)框架,它是各個(gè)應(yīng)用之間互聯(lián)互通的事實(shí)標(biāo)準(zhǔn)。注:OAuth 2.0 的發(fā)展也不是一帆風(fēng)順的,有興趣的讀者可以讀一讀OAuth 1.0 的作者 Eran Hammer 那篇著名的文章《OAuth 2.0 :通往地獄之路》,底部引用處有鏈接。3/ OAuth 2.0 為什么可以稱之為基石技術(shù)評(píng)價(jià)一樣?xùn)|西是不是重要的,可以想象一下如果沒有它,事情會(huì)變成怎樣的。如果沒有 OAuth 2.0 這類安全授權(quán)認(rèn)證框架,各個(gè)互聯(lián)網(wǎng)平臺(tái)之間無法互通,至少無法安全的互通,沒有互通,那便沒有交易往來,便不會(huì)有繁榮。如果說PC互聯(lián)網(wǎng)時(shí)代,網(wǎng)絡(luò)上的信息是一個(gè)巨大的數(shù)字花園,大家都可以從這個(gè)花園中生產(chǎn)和分享信息,但移動(dòng)互聯(lián)網(wǎng)的出現(xiàn),數(shù)字花園逐漸被圍欄花園所替代,每一個(gè)app都是獨(dú)立的數(shù)據(jù)孤島,每一家平臺(tái)都是各自為戰(zhàn)。如果圍欄花園之間沒有互聯(lián),如果沒有開放平臺(tái),那互聯(lián)網(wǎng)的發(fā)展不會(huì)繁榮至今。4/ OAuth 2.0 框架的實(shí)現(xiàn)流程 - 以第三方登錄場(chǎng)景說明上面寫了那么多,有點(diǎn)抽象,還是不夠直接具體。考慮到交社保的例子在實(shí)現(xiàn)方面涉及很多非本篇討論的金融知識(shí),本段落以一個(gè)用戶通過微信賬號(hào)登陸第三方應(yīng)用的例子,來簡(jiǎn)單說明 OAuth 2.0 協(xié)議的實(shí)現(xiàn)流程。
- 場(chǎng)景1:用戶輸入用戶名+密碼登錄微信
- 場(chǎng)景2:用戶使用微信賬號(hào)授權(quán)登錄小紅書(即第三方應(yīng)用)
關(guān)于場(chǎng)景2的實(shí)現(xiàn)過程如下(即:小紅書如何拿到用戶在微信側(cè)的登錄授權(quán)):注:上圖紅色部分的6個(gè)步驟即 OAuth 2.0 協(xié)議的基本原理
- 把第三方應(yīng)用和微信抽象為一切平臺(tái)與應(yīng)用
那么:涉及用戶、應(yīng)用和平臺(tái)之間的互聯(lián)互通場(chǎng)景,OAuth 2.0 的實(shí)現(xiàn)原理基本一致,作為開發(fā)者接入這些平臺(tái)需要實(shí)現(xiàn)的業(yè)務(wù)邏輯也基本趨同。下面是一些平臺(tái)/應(yīng)用公司的開放平臺(tái)說明,可以看到他們的實(shí)現(xiàn)流程基本與上述過程無異:
Oracle軟件
騰訊廣告
微信開放平臺(tái)
微信小程序
小米開放平臺(tái)
- https://datatracker.ietf.org/doc/html/rfc6749
- https://netapinotes.com/eran-hammers-oauth-20-road-to-hell/
閱讀原文:原文鏈接
該文章在 2025/4/14 10:25:51 編輯過