微信、支付寶以及美團等各大開放平臺是如何使用OAuth 2.0的？

在正式介紹各大開放平臺的使用細節以前，咱們先來看看大廠的開放平臺全局體系。據我觀察，各個開放平臺基本的系統結構和受權系統在中間的交互流程，大同小異，都是經過受權服務來受權，經過網關來鑑權。因此接下來，我就以京東商家開放平臺爲例，來和你說說開放平臺的體系究竟是什麼樣子的。開放平臺體系是什麼樣子的？咱們首先來看一下京東商家開放平臺全局體系的結構，以下圖所示。

咱們能夠把這個架構體系分爲三部分來看：

• 第三方軟件，通常是指第三方開發者或者 ISV 經過對接開放平臺來實現的應用軟件，好比小兔打單軟件。

• 京東商家開放平臺，包含 API 網關服務、OAuth 2.0 受權服務和第三方軟件開發者中心服務。其中，API 網關服務和 OAuth 2.0 受權服務，是開放平臺的「兩條腿」；

• 第三方軟件開發者中心服務，是爲開發者提供管理第三方軟件應用基本信息的服務，好比 app_id、app_secret 等信息。京東內部的各個微服務，好比訂單服務、商品服務等。這些微服務，就是咱們以前提到的受保護資源服務。

從圖中咱們還能夠看到這個體系總體的調用關係是：第三方軟件經過 HTTP 協議請求到開放平臺，更具體地說是開放平臺的 API 網關服務，而後由 API 網關經過內部的 RPC 調用到各個微服務。

接下來，咱們再以用戶小明使用小兔打單軟件爲例，來看看這些系統角色之間具體又是怎樣交互的？

到這裏，咱們能夠發現，在開放平臺體系中各個系統角色間的交互能夠歸結爲：

• 當用戶小明訪問小兔軟件的時候，小兔會首先向開放平臺的 OAuth 2.0 受權服務去請求訪問令牌，接着小兔拿着訪問令牌去請求 API 網關服務；

• 在 API 網關服務中，會作最基本的兩種校驗，一種是訪問令牌的合法性校驗，好比訪問令牌是否過時的校驗，另外一種是小兔打單軟件的基本信息的合法性校驗，好比 app_id 和 app_secret 的校驗；

• 都校驗成功以後，API 網關服務會發起最終的數據請求。

依靠開放平臺提供的能力，能夠說開放平臺、用戶和開發者實現了三贏：小明由於使用小兔提升了打單效率；小兔的開發者由於小明的訂購服務得到了收益；而經過開放出去的 API 讓小兔幫助小明可以極快地處理 C 端用戶的訂單，京東提升了用戶的使用體驗。

咱們已經知道，用戶給第三方軟件受權以後，受權服務就會生成一個訪問令牌，並且這個訪問令牌是跟用戶關聯的。好比，小明給小兔打單軟件進行了受權，那麼此時訪問令牌的粒度就是：小兔打單軟件 + 小明。

咱們還知道了，小兔打單軟件能夠拿着這個訪問令牌去表明小明訪問小明的數據；若是訪問令牌過時了，小兔打單軟件還能夠繼續使用刷新令牌來訪問，直到刷新令牌也過時了。

如今問題來了，若是小明註銷了帳號，或者修改了本身的密碼，那他以前爲其它第三方軟件進行受權的訪問令牌就應該當即失效。不然，在刷新令牌過時以前，第三方軟件能夠一直拿着以前的訪問令牌去請求數據。這顯然不合理。

因此在這種狀況下，受權服務就要經過 MQ（消息隊列）接收用戶的註銷和修改密碼這兩類消息，而後對訪問令牌進行清理。

其實，這個案例中解決訪問令牌安全問題的方式，不只僅適用於開放平臺，還能夠爲你在企業內構建本身的 OAuth 2.0 受權體系結構時提供借鑑。

以上就是開放平臺總體的結構，以及其中須要重點關注的用戶訪問令牌的安全性問題了。咱們做爲第三方軟件開發者，在對接到這些開放平臺或者瀏覽它們的網站時，幾乎都能看到相似這樣的一句話：「全部接口都須要接入 OAuth 受權，通過用戶確認受權後才能夠調用」，這正是 OAuth 2.0 的根本性做用。

理解了開放平臺的脈絡以後，接下來，就讓咱們經過一組圖看一看開放平臺是如何使用 OAuth 2.0 受權流程的吧。

各大開放平臺受權流程

咱們以微信、支付寶、美團爲例，看看它們在開放受權上是如何使用 OAuth 2.0 的。咱們首先看一下官方的受權流程圖：

引自微信官方文檔

引自支付寶開放平臺文檔

引自美團外賣開放平臺

咱們能夠在這三張受權流程圖中看到，都有和受權碼 code 相關的文字。這就說明，它們都建議開發者首選受權碼流程。

總結

• 當有多個受保護資源服務的時候，基本的鑑權工做，包括訪問令牌的驗證、第三方軟件應用信息的驗證都應該抽出一個 API 網關層，並把這些基本的工做放到這個 API 網關層。

• 各大開放平臺都是推薦使用受權碼許可流程，不管是網頁版的 Web 應用程序，仍是移動應用程序。

• 對於第三方軟件開發者重點關注的參數，能夠從受權服務的受權端點和令牌端點來區分，受權端點重點是受權碼請求和響應的處理，令牌端點重點是訪問令牌請求和響應的處理。