我最近一直在研究OAuth2,我想我理解授權過程。OAuth2(承載)令牌如何轉換爲ACL
然而,似乎我不明白的是,一旦授權已經發生和access_token
和refresh_token
已經建立撥打電話,怎麼會是決定基礎上作出的access_token
如果請求可以或不可以訪問一個特定的資源?
I.e.令牌被髮送到服務器以請求照片。服務器上的邏輯如何根據給定的標記確定是否允許或拒絕特定照片的訪問?
我最近一直在研究OAuth2,我想我理解授權過程。OAuth2(承載)令牌如何轉換爲ACL
然而,似乎我不明白的是,一旦授權已經發生和access_token
和refresh_token
已經建立撥打電話,怎麼會是決定基礎上作出的access_token
如果請求可以或不可以訪問一個特定的資源?
I.e.令牌被髮送到服務器以請求照片。服務器上的邏輯如何根據給定的標記確定是否允許或拒絕特定照片的訪問?
access_token
通常是一個不透明的神器。沒有任何內容將其與資源(例如特定照片)相關聯。當授權流程開始時,您通常會請求特定的scope
來定義您需要的訪問權限。如果資源的所有者同意此訪問,則請求成功。用戶也可以撤消訪問權限。
所有這些都是特定於應用的代碼。每個應用程序定義他們的範圍和他們如何執行檢查。
您可能想要探索Authorization Server爲例。
訪問令牌實際上是一個加密對象,該對象定義了範圍並可能重新建立授權。
想象一下,服務提供商給你一個HMAC加密的令牌,這對你來說沒有意義,但端點知道如何解密它。在解密,那就有這樣的信息:
{"scope":"Photos", "userID":"3refefe"}
因此,基本模塊處理過的令牌,你這個加密JSON(或任何其他形式)對象,併爲您提供了加密令牌。當您點擊API端點時,它將令牌發送給解密邏輯並獲取此JSON對象,從而知道您擁有的所有權限。
此對象可以包含任何類型的信息,並且可以使用任何格式,具體取決於服務提供者。我已經描述過 how an OAuth provider works here.
這應該解釋一個極簡主義OAuth框架的基礎知識。
對OAuth(2)有更多的經驗,這個答案實際上是正確的答案。 – Luke