2012-03-06 61 views
2

我正在研究通過HTTP公開的API,這些API將由合作伙伴公司使用並部署到他們衆多的客戶端。保護HTTP API - 沒有用戶密碼提示並避免公開私鑰

在某些情況下,客戶端將基於瀏覽器。這是我的主要關注點,但我可能會在客戶端是Windows應用程序的情況下應用相同的模式。我認爲,當它是一個Windows應用程序而不是基於瀏覽器的應用程序時,在客戶端上獲得私鑰的範圍更大。所以發生的通信來自合作伙伴應用程序呈現給我們的服務器的瀏覽器頁面,我們託管我們的API。

底線是我們不能提示最終用戶輸入憑證,並且必須依靠每個請求都會傳遞的存儲密碼/密鑰/令牌。我擔心的是,我想阻止合作伙伴公司將此令牌烘焙成客戶端代碼。以下是場景的高級描述。

  1. 合作伙伴建立與我們(手動過程)的賬戶,進行了必要的開發工作,以消耗他們的產品的API,然後滾出來給他們的客戶。
  2. 然後客戶運行產品並通過嚮導建立他們的賬戶。我們可以在這時提示他們輸入用戶名和密碼,但是以後對API的所有請求都不應該提示實際最終用戶輸入憑據。
  3. 然後,他們執行許多業務流程,在許多不同的用戶環境下在許多工作站上調用我們的API。我們不關心個人用戶信息。

對於我將跳過步驟1,注重執行步驟2和3

我目前的工作,以確保該API,並想出了下面的這個問題的目的設計:

  • HTTPS到處(所有請求使用SSL/TLS)
  • 所有POST請求利用CSRF令牌
  • 在步驟2中,當客戶端創建的我們爲他們提供了一個客戶端身份驗證碼。合作伙伴應該編寫他們的應用程序來存儲這個授權碼到服務器上。
  • 在未來調用我們的API之前,他們調用我們的JavaScript庫上的Init函數並提供回調,如「GetAuthToken」。
  • 在每次調用我們的API時,我們檢查我們是否有Auth令牌(在服務器上),如果沒有,我們會返回一個錯誤並調用回調。
  • 執行回調時,合作伙伴應該使用HTTPS調用其服務器來檢索令牌。這個請求將受到他們的正常認證,所以假設如果用戶在他們的系統中被認證,那麼他們可以檢索認證令牌。
  • 我們收到驗證令牌,調用我們的服務器來驗證它,然後設置一個包含令牌的HTTPOnly cookie。
  • 當cookie過期時,我們再次調用GetAuthToken回調函數。
  • 跨域問題正在使用的postMessage
  • 我們可以使身份驗證令牌撤銷

我們必須聯合安全的形式在這裏,如果用戶與當時的合作伙伴認證,我們假定他們有權訪問管理我們的API。我認爲避免將私鑰/授權令牌燒入客戶端代碼的唯一方法就是這種回調機制。

我是否過於複雜?還有其他更簡單的方法嗎?我意識到,如果任一站點對XSS開放或受到惡意軟件攻擊,所有賭注都將關閉,但至少不會將私鑰轉換爲javascript或標記,用戶無法右鍵單擊查看源並將所有私鑰告訴所有人。

編輯:發現這個問題。最佳答案描述了類似於我所描述的內容,但提到WIF,我不想強​​迫合作伙伴實施(他們甚至可能不會運行Windows)。還是想對我的做法,雖然反饋...

Web Application - User Authentication Across Domains

+0

您可以添加有關客戶端上下文的詳細信息 - 服務器服務器還是瀏覽器到服務器?聽起來像瀏覽器,但要確保。 – hoserdude 2012-03-07 19:48:01

+0

@hoserdude - 謝謝,我添加了一些關於客戶背景的說明。這是瀏覽器,我主要關心的服務器。 – tidmutt 2012-03-07 19:52:31

回答

0

我知道你所要求的簡化,但你走了下來探索SAML聯邦路的地方,當他們推出各自的合作伙伴聲稱自己的身份與你該應用程序,並使用您的身份驗證令牌cookie他們?它避免了JS被牽涉進來,並且與SSL + CSRF令牌一起使用,使您處於一個不錯的位置。

+0

謝謝,我已經考慮了SAML SSO,但似乎合作伙伴的客戶端部署將充當身份提供商,將合作伙伴的這一部分流程實施起來,這可能是我認爲的一個難題。我假設合作伙伴需要實現發佈SAML令牌的功能?像這裏描述的: http://support.onelogin.com/entries/20186386 也許我誤解你的方法?我對這裏的建議非常開放,我對SAML聯盟的理解充其量是最基本的。 – tidmutt 2012-03-08 17:04:30