2012-02-23 112 views
1

考慮使用OAuth 2.0進行授權和OpenID 2.0進行身份驗證的以下分佈式系統。如何安全使用OAuth 2.0的多個資源服務器?

enter image description here

  1. RS1,RS2和RS3是 「資源服務器」(又名三種不同的REST API)
  2. APP1和APP2是客戶
  3. AS是一個「授權服務器「用於管理OAuth令牌
  4. OPENID是一個OpenID 2.0提供程序。

APP2使用RS1,RS1又使用RS2和RS3上的資源。 RS1,RS2,RS3,APP2,AS和OPENID之間存在信任關係,因爲它們是由同一家公司(但不同的團隊)開發的。當用戶第一次訪問APP2時,APP2被自動授權以代表用戶訪問RS1,RS2和RS3上的資源。

APP1使用RS2中的資源,而RS2又使用RS3中的資源。 APP1是不受信任的第三方網站,用戶需要明確授權APP1訪問RS2和RS3上的資源。

有關OAuth 2.0的大多數示例都顯示了單個資源和授權服務器之間的通信以及如何請求,發放和管理令牌。

如何使用OAuth 2.0保護此環境?例如,APP2,RS1和RS2是否有自己的客戶端標識符和客戶端密鑰(因爲它們都是另一臺服務器的「客戶端」)?如果是這樣,當RS1嘗試在另一個請求(來自APP2)的第一次嘗試訪問RS2和RS3上的資源時,如何爲RS1發出令牌?

我已經有AS,OPENID,APP2和RS1,它是使用ASP.NET MVC 3,WCF 4和DotNetOpenAuth 4開發的。我試圖將RS2,RS3和APP1引入系統,但很難弄清楚資源服務器和客戶端之間的授權如何工作。一切都在IIS 7.5和HTTPS下運行。

回答

0

我認爲APP2是一個網絡應用程序,因爲任何其他類型的應用程序一旦下載到客戶端機器就不能被「信任」。

我認爲,只要使用客戶端憑據對您的可信應用程序進行身份驗證,您就是對的。 DotNetOpenAuth 4.0測試版尚不支持客戶端憑證,但希望在下週左右發佈。

在OAuth 2中,客戶端憑證將內置到您的可信客戶端中。這些憑證將在運行時進行交換,以刷新和訪問令牌,並將其發送到資源服務器。您可以使用DNOA API將訪問令牌應用於每個出站HTTP請求,該DNOA API將通過對授權服務器的另一請求自動續訂任何過期的訪問令牌。

+0

是的,APP2是一個用ASP.NET MVC 3編寫的web應用程序。 – bloudraak 2012-02-23 19:40:47

+0

假設「bob」訪問APP2,它在訪問RS1時具有訪問令牌(表示「bob」)。如何將RS1到RS2的請求識別爲代表「bob」而不是其他人的請求。唯一想到的解決方案是RS1爲每個用戶提供唯一的客戶端憑證,並查找這些客戶端憑證並在從RS2請求資源時使用它。這在憑證管理方面提出了一些挑戰。 – bloudraak 2012-02-23 20:04:58

+0

既然你說RS *是可信的,他們不需要每個用戶的訪問令牌。只是他們的一套客戶端憑證就足夠了,只需提供他們正在模仿的用戶的話。例如,RS1告訴RS2「給我bob的數據,這裏是RS1的客戶端憑證」RS2滿足RS1發出請求並因此響應bob的數據。 – 2012-02-24 14:09:31

相關問題