oAuth2.0訪問令牌混淆

我正在關注本教程中有關OAuth2.0的信息https://developers.google.com/youtube/v3/guides/authentication oAuth2.0訪問令牌混淆

OAuth2.0的工作原理很清楚。但是我對訪問令牌部分有點困惑。

在獲取用戶的訪問令牌後，您的應用程序可以使用該令牌以該用戶的名義提交授權的API請求。該API支持兩種方式來指定訪問令牌：指定訪問令牌作爲查詢的access_token參數的值：

www.googleapis.com/youtube/v3/videos?access_token=ACCESS_TOKEN

如果有人在URL傳輸過程中獲得了此訪問令牌，他們可以訪問此受保護的資源嗎？

服務器如何知道請求是否來自最初請求訪問令牌的客戶端？

更新： 看完這篇文章Are HTTPS headers encrypted?我的困惑被清除了。我認爲查詢字符串在網絡傳輸過程中沒有加密。

來源

2013-05-06 wwli

一般而言，我認爲OAuth 2.0是服務器端技術，所有訪問令牌和通信都應使用SSL傳輸，因爲承載令牌需要儘可能保持安全。

來源

2013-05-06 21:11:44 Jammer

在此請求中，我認爲www.googleapis.com/youtube/v3/videos?access_token=ACCESS_TOKEN ACCESS_TOKEN是url的一部分。這不安全嗎？爲什麼谷歌像這樣傳遞訪問令牌？ – wwli 2013-05-06 21:16:18

另外，你需要知道，有兩種類型的OAuth的流量2.0
我）隱性補助流 - 這是在給服務提供商的用戶登錄和他的瀏覽器獲得訪問令牌中的流。假設你有X.com並通過Facebook登錄。一旦用戶鍵入他的FB憑證，訪問令牌就會發送到他的瀏覽器。

ii）授權碼流程 - 在此流程中（再次考慮上述情況），facebook會將授權碼傳遞給用戶的瀏覽器。如果有人以某種方式攔截授權碼，那麼他無能爲力。使用有效的客戶端憑證傳遞授權碼時可以交換訪問權限。所以，當用戶登錄時，他的瀏覽器會獲得一個授權碼，並將其傳遞給X.com上的服務器。從那裏你可以打到FB提供的代碼令牌交換端點，並將訪問令牌返回給你的服務器！

授權代碼流添加了另一個安全層，其中訪問令牌僅對客戶端+服務器可見，而對用戶代理不可見。當你自己想出來的時候，令牌就通過HTTPS傳遞。

來源

2013-05-07 04:30:48 divyanshm

那麼在授權代碼被截獲的同時，惡意攻擊者故意延遲響應的情況（可能有點人爲的）呢？然後，攻擊者將在瀏覽器中輸入截獲的URL（具有授權碼），以便即時訪問受害者的資源。當然，邪惡先生可以自動化整個過程，所有受害者都將被拒絕訪問，因爲訪問令牌已經被交換。 – simou 2015-09-16 10:44:39

oAuth2.0訪問令牌混淆

回答

相關問題