0
我已讀的OAuth的不同的流,並具有關於授權碼流混亂。據說,授權碼流更安全,因爲即使授權碼,同時轉移劫持,這是沒用的黑客,因爲黑客需要在客戶端ID和客戶端密鑰,以獲得訪問令牌 - 但如果當客戶端在收到授權碼後請求訪問令牌,黑客竊聽傳輸並獲取訪問令牌? 我不知道,但它看起來像授權代碼只添加一個額外的安全層,但實際上並不完全固定的訪問令牌。 我對不對?請糾正我。授權碼流OAuth中可以攔截訪問令牌嗎?
我已讀的OAuth的不同的流,並具有關於授權碼流混亂。據說,授權碼流更安全,因爲即使授權碼,同時轉移劫持,這是沒用的黑客,因爲黑客需要在客戶端ID和客戶端密鑰,以獲得訪問令牌 - 但如果當客戶端在收到授權碼後請求訪問令牌,黑客竊聽傳輸並獲取訪問令牌? 我不知道,但它看起來像授權代碼只添加一個額外的安全層,但實際上並不完全固定的訪問令牌。 我對不對?請糾正我。授權碼流OAuth中可以攔截訪問令牌嗎?
典型的用例的授權碼流是令牌請求(即交換授權代碼的訪問令牌之一)做了一個TLS保護的暗道,這意味着攻擊者無法得到它 - 除非他能夠打破SSL,在這種情況下會出現更大的問題。
但前路使用的情況下,即在一個瀏覽器的JavaScript應用程序或單頁應用程序你是對的:黑客可能幾乎一樣容易攔截令牌請求的重定向。這也是爲什麼這個用例不能使用一個機密的客戶端,因爲這個祕密太容易被暴露。
你好,你說的「授權碼流是令牌請求(即交換授權代碼的訪問令牌之一)通過TLS保護暗道完成」但如果這個流用於通過TLS保護的反向通道,爲什麼auth服務器在用戶認證應用時不能返回訪問令牌而不是認證碼? –
因爲這將是與授權碼流中的前聲道,通過定義 –
@HansZ您好。我不同意你答案的第二部分。 RFC6749不阻止公共客戶端使用授權碼流程。 防止使用截取的身份驗證發出訪問令牌。代碼與這種客戶端類型,RFC7636引入了一個代碼驗證器。草案https://tools.ietf.org/html/draft-ietf-oauth-security-topics-03#section-5.1.1表明它是原生應用的首選方式。 –