0
如果使用客戶端流,回調URL包含訪問令牌。因此,如果通過HTTP發送回調URL,是不是很容易被捕獲和濫用。在oAuth2中竊取訪問令牌
如果我的應用的用戶2獲取用戶1的訪問令牌,他可以訪問用戶1的帳戶。
此外,如果用戶複製回叫網址並將其發送給某人,他會不知不覺地將其他人訪問他的帳戶。
我能想到的緩解的某些方面,這 - 使回調URL HTTPS,並在客戶端腳本從URL等刪除訪問令牌是如何你預計處理這個
如果使用客戶端流,回調URL包含訪問令牌。因此,如果通過HTTP發送回調URL,是不是很容易被捕獲和濫用。在oAuth2中竊取訪問令牌
如果我的應用的用戶2獲取用戶1的訪問令牌,他可以訪問用戶1的帳戶。
此外,如果用戶複製回叫網址並將其發送給某人,他會不知不覺地將其他人訪問他的帳戶。
我能想到的緩解的某些方面,這 - 使回調URL HTTPS,並在客戶端腳本從URL等刪除訪問令牌是如何你預計處理這個
的客戶方流在URL的散列部分發送oauth_token(/path?#access_token=abcdef
),而不是在查詢部分。接收客戶端將其存儲在sessionStorage
(或其他)中是一個好主意,最後使用window.location.hash = '';
將其從URL中刪除。
謝謝湯姆。是的,這也是我的想法,存儲令牌並將其從url/hash中移除。你怎麼看待使用HTTP的回調URL。這不是不安全的嗎(例如,如果我可以監聽網絡流量,我將能夠看到某人的訪問令牌爲純文本)?我們應該使用HTTPS嗎?當你在註冊你的應用程序時指定一個回調URL時,我感到很驚訝,這不是由Google等強制執行的。 – Aishwar
散列實際上不是在HTTP請求中發送的,它是客戶端的事情。只有重定向的服務器才知道access_token,並且該服務器應該具有SSL(根據OAuth規範)。如果規範完全實現,則OAuth 2的服務器實現可以被認爲是安全的。 –
啊,我明白了。當谷歌重定向到回調url時,我的印象就是這樣,如果請求/響應被檢查,這個整個url將是可見的 - 但似乎並非如此(用Fiddler檢查)。感謝你的回答 :) – Aishwar