OAuth2返回JWT代替access_token

我目前正在使用bshaffer PHP庫here構建OAuth2提供程序。OAuth2返回JWT代替access_token

我發現了IETF draft specifications，它們概述了具體調用JSON Web Tokens作爲授權授權和客戶端認證的實現。

然而，我感興趣的實現是返回JWT來代替常規訪問令牌，如here所示。在死鏈接的情況下，訪問令牌響應被粘貼在下面。

{  
    "access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpZCI6IjYzMjIwNzg0YzUzODA3ZjVmZTc2Yjg4ZjZkNjdlMmExZTIxODlhZTEiLCJjbGllbnRfaWQiOiJUZXN0IENsaWVudCBJRCIsInVzZXJfaWQiOm51bGwsImV4cGlyZXMiOjEzODAwNDQ1NDIsInRva2VuX3R5cGUiOiJiZWFyZXIiLCJzY29wZSI6bnVsbH0.PcC4k8Q_etpU-J4yGFEuBUdeyMJhtpZFkVQ__sXpe78eSi7xTniqOOtgfWa62Y4sj5Npta8xPuDglH8Fueh_APZX4wGCiRE1P4nT4APQCOTbgcuCNXwjmP8znk9F76ID2WxThaMbmpsTTEkuyyUYQKCCdxlIcSbVvcLZUGKZ6-g", 
    "client_id":"CLIENT_ID", 
    "user_id":null, 
    "expires":1382630473, 
    "scope":null 
}

到位的正常授權補助定期生成的訪問令牌的返回JWT。客戶和用戶憑據授權對我來說更爲重要，因爲我們只處理第一方API訪問。

此實現看起來很理想，因爲我不需要維護一個生成的令牌存儲區，從而限制了所需的基礎架構數量。在某些時候，如果我們向第三方開放API，我們需要一個用於各種pub/priv密鑰的密鑰存儲區來驗證每個客戶端的令牌，並在某些惡意方偷走加密密鑰時限制風險。

我覺得這是一個很好的依賴於非對稱加密和SSL/TLS的實現。但是，我是否存在潛在的安全風險？

來源

2014-10-29 Jamie

你的問題的真實性，你得到的標記示例不使用標準的JWT索賠。例如，它具有'client_id'而不是'sub'（這可能來自舊規格，目前的要求在這裏：https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-11 ＃section-3） – stash 2014-10-30 16:43:34

謝謝！我從中得到迴應的文檔必須是過時的，v1.5正在生成帶有「sub」，「iss」等的標記。請注意仔細檢查。 – Jamie 2014-10-30 17:42:12

缺點是，如果沒有令牌數據庫，您無法撤消發佈的JWT令牌。 – 2014-10-31 10:13:12

JWT上的簽名只會保護內的所有內的篡改，但不能保護令牌外部的聲明。因此，您的結構中的expires字段未受到保護，可能會被篡改。

爲了防止篡改，您要使用exp claim。

兩個有效的解決方案是：

仔細檢查expires對exp

下降expires，只是使用exp

你可能更喜歡一個比其他根據您的要求。就個人而言，我會保持簡單，並遵循（2）

來源

2014-10-30 16:42:40 stash

我喜歡你關於exp的建議。問題：如果我正在實現refresh_token流，我應該在JWT中將刷新標記添加爲聲明還是將其添加爲refresh_token JSON屬性？ – 2015-02-03 21:28:34

我建議您將其添加爲refresh_token JSON屬性。註銷時，您可以撤銷access_token或refresh_token – Vikash 2015-03-04 07:26:14

OAuth2返回JWT代替access_token

回答

相關問題