2016-05-04 95 views
5

我有一個基於Jersey的服務器,我想用OAuth 2.0加密。有兩條我認爲常見的路徑:將Oauth 2.0添加到基於Jersey的RESTful服務器

  • Oltu - 兼容Jersey並且似乎被支持,雖然不如Spring Security。 This 2012 question似乎表明這是要走的路,但我希望在2016年的背景下得到確認,所以我不會實施一些不再支持的事情。
  • Spring Security - 它似乎非常流行,但是這條路徑意味着將服務器變成基於Spring的MVC。我不知道基於使用像Spring這樣得到廣泛支持的東西的好處以及重構的成本,這是否值得推薦。

有了支持,我的意思是一個持續發展的項目,建立完善的社區,包括爲客戶提供的教程,材料和一些庫(Web,移動,服務器)。

哪一個是更強的選項?還有其他選擇嗎?

無論如何。有沒有一個很好的參考資料或教程來開始實施?


UPDATE

約兩個我曾提到的OAuth提供者,我覺得閱讀和理解幾個小時後阿帕奇Oltu的documentation沒有指導我多有不記錄關鍵部件但是,example給了我一個關於如何實現Oltu的更好的圖片。另一方面,通過Spring Security's material我知道它仍然可以建立在基於非Spring MVC的java項目上。但是,在基於非Spring的項目上,Spring Security的實現/教程暴露有限。

另一種方法:

我想出了一個架構,可能會更穩定,不會在乎內部服務器(使用新澤西州已經實施的一個)的實施細則。有一個專門用於安全目的的服務器(在其自己的數據庫中授權,認證,存儲令牌等)在中間扮演着外部世界和內部服務器之間的網關的角色。它本質上是一箇中繼,並且來回路由這些調用,並確保客戶端對內部服務器一無所知,並且這兩個實體只與安全服務器進行通信。我覺得這將是前進的道路,因爲

  1. 替換與另一個安全提供商只是意味着插入安全服務器實施並添加新的。
  2. 安全服務器不關心內部服務器的實現,並且調用仍然遵循RESTful標準。

我感謝您對此方法的建議或反饋。

回答

0

我認爲,使用在澤西本身內部實現的oauth連接器要簡單得多! 您是否考慮過使用球衣自己的OAuth(已經鏈接球衣)服務器/客戶端? https://jersey.github.io/documentation/latest/security.html#d0e12970

請看一看到:

16.3.2。 OAuth的2支持

希望幫助。 :)

+3

Jersey的OAuth 2支持僅適用於客戶端。 –

+0

Takahiko川崎,我一直在閱讀這個問題,我不認爲vardhinisuresh27要實現是自己的oauth內部機制。爲什麼不使用已經開發和提供的? – jeorfevre

+0

如果vardhinisuresh27想要實現OAuth 2.0 _client_,則可以使用Jersey的OAuth 2.0支持。另一方面,如果他想要一個OAuth 2.0服務器,我必須指出,澤西島不支持這種情況。因爲他提到了Oltu和Spring Security,它們都是OAuth 2.0服務器解決方案,所以我認爲他想實現OAuth 2.0服務器。 –

1

阿帕奇Oltu支持OpenID Connect但其結構是不好的。例如,OpenIdConnectResponse不應該是OAuthAccessTokenResponse的後裔,因爲ID連接反應並不總是包含一個訪問令牌。此外,圖書館古怪包含GitHub的特定類,GitHubTokenResponse

Spring Security是有名的,但恐怕它永遠無法支持OpenID Connect。有關OpenID Connect支持的大障礙,請參見Issue 619

java-oauth-serverjava-resource-server是新澤西+ OAuth 2.0用戶很好的例子,但他們使用商業後端服務,Authlete。 (我是他們的作者。)

OpenAMMITREid連接GLUUConnect2id,和其他的OAuth 2.0 + ID連接解決方​​案在Libraries, Products, and Tools頁面OpenID基金會的上市。


UPDATE的問題

RFC 6749(OAuth 2.0已授權框架)的更新從資源服務器區分一個授權服務器。總之,授權服務器是發出一個訪問令牌服務器,資源服務器是響應與訪問令牌一起去請求的服務器。

對於資源服務器,API網關是最近的設計模式之一。亞馬遜,CA Technologies,IBM,Oracle和其他公司提供API網關解決方案。 API網關架構可能接近您的想法。一些API網關解決方案驗證的訪問令牌以自己的方式(因爲自己的解決方案問題訪問令牌)和其他解決方案只是委派訪問令牌驗證到外部服務器(因爲該解決方案沒有一個機制來發出訪問令牌)。例如,Amazon API Gateway是代表訪問令牌驗證到外部服務器,亞馬遜已經任命定製授權一個例子。有關自定義授權人的更多信息,請參閱以下內容。

如果授權服務器提供了一個自省API(如RFC 7662),您可以使用查詢有關訪問令牌的信息時,您的資源服務器實現可以替換(插件和添加)授權服務器以相對容易地引用。

對於一個athorization服務器,網關式解決方案很少見。這是因爲這樣的解決方案必須公開實現授權服務器所需的所有功能爲Web API。 Authlete就是這樣的解決方案,但我不認識其他人。

+0

@ vardhinisuresh27我更新了我的答案,以解決您的其他問題。 –