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