OAuth 2.0只是授權協議，OIDC才是認證授權協議
上一文我們對Keycloak保護Spring Boot應用進行了實操。讓大家見識到了Keycloak的強大。為了掌握Keycloak就必須對OpenID Connect(OIDC)協議進行了解。OIDC是OAuth 2.0的一個擴展協議。它為什么要擴展OAuth 2.0?在搞清楚這個問題之前我們需要再回顧一下OAuth 2.0協議。
OAuth 2.0
以往胖哥也說了不少OAuth 2.0協議相關的東西，但是依然讓大家云里霧里。所以今天我們換一個角度來說一說OAuth 2.0。如今利用這個協議搞開放API的越來越多了。
為什么要開放授權
假如我開發了一個互聯網照片存儲服務，這里叫它XX相冊存儲服務，經過精心的運營用戶量達到了一定的規模，這個時候往往會進入一個瓶頸期，我希望進一步提升這個品牌的知名度以改變這種現狀。而另一個第三方照片打印平臺也看中了我的獨特優勢，希望我能開放一些功能出來給他們調用。
強強聯合，做大做強!我覺得這是一個好主意，它用了我的開放服務后也可以幫我引流用戶、擴大我的影響力。從用戶角度來看，可以同時享受照片云儲存、云打印服務是非常具有吸引力的。所以開放一些功能給第三方是非常劃算的。
客戶端授權接入
雖然開放授權的好處很多，但是也不能沒有規則。用戶的隱私保護、數據安全都是非常重要的。經過仔細斟酌，我確定了下面幾條開放的原則：
- 第三方需要在我的平臺開個戶，這樣方便我對第三方平臺進行管理和審計。哪個第三方不合規我就限流甚至封停其資格。
- 明確開放的接口類目并對其進行權限分類。用來滿足不同層次的第三方。有的第三方只能獲取用戶信息;有的第三方可以調用云打印。方便后續收費恰飯。
- 調用這些服務必須征求照片的實際擁有者(資源擁有者)同意，這是一個法律問題。獲取用戶的信息和資源必須征得用戶同意才行。
于是第三方打印平臺按照我制定的規則提請了一個接入申請，審核通過后我給他發了一套客戶端憑證，包含了clientId和對應的secret，并明確告知第三方可以申請哪些功能，然后第三方就可以根據API文檔進行開發了。
授權流程
用戶登錄了照片打印平臺，發現居然還提供從XX相冊存儲服務拉取照片打印的功能。便興沖沖地嘗試了一下 。大致的過程是這樣的：
- 用戶告訴打印平臺: 聽說你能從XX相冊存儲服務把我照片給拉過來打印，給我操作一下。
- 打印平臺回復用戶：沒問題，不過我得先給XX相冊存儲服務說一下。我得帶上我自己的標識clientId，還有你請求的事項權限scopes。以及遵循的流程類型authorizationGrantType。為了安全起見我們最好弄個state隨機碼防止中間人攻擊。XX相冊存儲服務會通過我提供的專線redirectUri進行給您確認，您到時候確認一下。
- XX相冊存儲服務向用戶確認：您是不是要授權給XX打印平臺拉取您的照片?
- 用戶確認的話需要向XX相冊存儲服務提供自己的用戶憑證并確認;否則拒絕，流程到此結束。
- XX相冊存儲服務收到用戶的確認信息后回復打印平臺: 用戶確認過了，給您一個臨時憑證code(authorizationGrantType=code) ，你來換Token然后就可以憑此拉取該用戶的照片了。
- 打印平臺換取了Token成功地拉取了該用戶的照片并打印。
- 用戶不用來回奔波就享受了跨平臺云打印服務，用戶體驗度得到了提升。
OIDC的產生背景
OAuth 2.0協議只解決了授權的問題，客戶端只要得到了資源所有者的授權就能訪問資源。OAuth 2.0本身并沒有提供用戶認證的規范。
OAuth 2.0本身無法證明資源所有者就是正確的資源所有者。OAuth 2.0中涉及的用戶認證都建立在其它認證的可靠性之上，OAuth 2.0只消費認證的結果并不參與認證的流程。
基于這個原因OpenID Connect誕生了。它和OAuth 2.0的關系是這樣的：
- interface OIDC extends OAuth2{
- boolean authentication ()
- }
也就是說OIDC 在OAuth 2.0 的基礎之上增加一個對資源所有者的認證流程，實現了真正意義上的認證授權。基于篇幅的原因，我會在后續系列文章中和大家共同學習OIDC協議。如果你有什么疑問可以留言討論。
本文轉載自微信公眾號「碼農小胖哥」，可以通過以下二維碼關注。轉載本文請聯系碼農小胖哥公眾號。
