使用OAuth2承載令牌保護映像資源

我已經創建了許多生成/使用JSON數據的Web服務，並且我使用OAuth2和承載令牌保護了它們，這些工作正常。使用OAuth2承載令牌保護映像資源

但是現在我需要構建一個類似的Web服務來生成圖片而不是JSON（所以JPEG/PNG數據）。爲了保持一致性我也想用的OAuth2 /承載令牌保護服務，但這樣做會使得服務更具挑戰性在那些希望使用<IMG>標籤來顯示圖像數據的基於瀏覽器的應用程序消耗，因爲<IMG>標記不會發送必要的Authorization: Bearer ...bearer-token... HTTP標頭。

我可以看到兩種方式這一輪：

基於瀏覽器的服務將使用XHR 2級以及斑點和斑點URL方案從HTML5的客戶端來獲取圖像數據的Blob，使用BLOB URL方案來爲Blob生成一個URL，然後動態地創建一個引用Blob URl的img標籤。很多工作只是爲了顯示圖像！
修改OAuth2基礎結構以生成除承載令牌之外的Http cookie。修改服務授權以接受授權：承載... OAuth2頭或作爲身份證明的cookie。 Cookie與持票人標記，httpOnly等具有相同的生命週期。基於瀏覽器的客戶端可以僅依靠瀏覽器cookie支持來訪問服務，可以通過<標籤正常地參照圖像數據。易於使用瀏覽器客戶端，但非標準。無論是持票人還是Cookie，安全風險配置文件都是相同的。

我是否忽略了後一種方法的安全問題？

是否有任何替代方法來保護OAuth2的圖像/媒體資源？

來源

2012-12-05 cdivilly

我假設您正在使用user-agent-based application配置文件來獲取不記名令牌到瀏覽器應用程序中。

的OAuth的承載令牌規範支持發送該令牌作爲查詢參數?access_token=mF_9.B5f-4.1JqM。您的瀏覽器中的JavaScript可以將令牌作爲查詢參數添加到您的img鏈接中。

這將基於更多的標準，但那麼你將不得不擔心access_token價值泄漏在日誌等我認爲安全權衡將真正取決於那些持票人的範圍，這些是多麼重要圖像是要保護的。

我認爲打開您的OAuth基礎設施來接受cookie可能會讓您面臨新的攻擊媒介。 RFC 6750特別呼籲CSRF攻擊的風險

Implementations that do store bearer tokens in cookies MUST take precautions 
against cross-site request forgery.

來源

2012-12-05 18:42:11 Patrick

我忘記/打折了查詢參數機制，顯然這是它的設計用例，謝謝。 – cdivilly

這是否意味着，在服務器端（可能在過濾器中），我們需要先檢查'授權'標題;如果它是空的，請檢查'request.getParameter（「access_token」）'？ –

使用OAuth2承載令牌保護映像資源

回答

相關問題