2017-02-14 16 views
1

我的網站上有一些REST服務,可供第三方訪問。 我的計劃很簡單。爲了呼叫這些服務,他們需要向我請求一個密鑰。我會私下給他們提供一個GUID。對我的任何服務的每次呼叫都將通過過濾器檢查密鑰的標頭並相應地接受/拒絕該請求。 此網站全是HTTPS,因此密鑰在傳輸過程中會被加密。我並不擔心授權客戶在視覺上可識別的關鍵。換句話說,我並不擔心任何「內部」攻擊或共享密鑰的人。我只是不想隨機的,未經授權的外部用戶。只需發送HTTP頭中的密鑰以進行REST調用的認證?

我環顧四周,我真的沒有看到任何人究竟做這種方式。我覺得我過於簡單化......但另一方面,我也沒有看到它有什麼問題。

我的問題是..沒有這種聲音足夠安全的(從基本/最小角度)或它暴露的是我沒有看到一些巨大的安全孔?

FWIW - 我使用Spring框架,包括Spring安全4.

謝謝!

+0

聽起來像一個基本的API密鑰實施等我會檢查[這出第一(https://stackoverflow.com/questions/25317405/securing-rest-api-using-custom-tokens-stateless-no- UI-沒有餅乾,沒有基本-AU)。 – dkanejs

+0

是的。對不起,我原來的信息並不清楚。我已經有這個了。它的生活和運作良好。我的問題更多的是......它是否足夠安全(從基本/最小的角度來看)還是它暴露了我沒有看到的一些大的安全漏洞?我會更新原始帖子。 –

+0

酷,這是一個非常常見的模式,有時最小的方法是最好的。我已經提交了一個可以使用的附加方法的答案。 – dkanejs

回答

2

如果是HTTPS和API密鑰是在運輸過程中加密的標頭,如您所描述等,然後它遵循一個非常標準的設計認證模式。

您的安全現在取決於您如何分配和存儲您的API密鑰。

雖然,你可以使用一個 「​​」 的做法。

儘管API密鑰模式結合了應用 和一個令牌祕密使用令牌的身份,這種模式分離 兩項。每個使用API​​的應用程序都會發佈一個不可變的初始標識符,稱爲應用程序標識(應用程序標識)。應用ID是 不變,可能是也可能不是祕密。另外,每個應用程序 可以具有1-n個應用程序密鑰(App_Keys)。每個密鑰都直接與App_ID關聯 ,應視爲祕密。

萬一你想擴展在未來的應用。

相關問題