將 Oauth 2.0 添加到基於 Jersey 的 RESTful 服務器

Question

我有一個基於Jersey的服務器，我想用OAuth 2.0來保護它。 我認為有兩條路徑很常見：

• Oltu - 與 Jersey 兼容並且似乎受支持，但不如 Spring Security。 這個 2012 年的問題似乎表明這是要走的路，但我想確認 2016 年的上下文，所以我兒子不再實施不受支持的東西。
• Spring Security - 它似乎很流行，但這條路徑意味着將服務器更改為基於 Spring 的 MVC。 我不知道根據使用像 Spring 這樣廣泛支持的東西的好處和重構的成本，這是否值得推薦。

支持我的意思是一個持續開發的項目，完善的社區，已經提供了教程、材料和一些客戶端（網絡、移動、服務器）庫。

哪個是更強的選擇？ 還有其他選擇嗎？

無論如何。 是否有很好的參考資料或教程來開始實施？

---

更新

在閱讀和理解我提到的兩個 OAuth Providers 幾個小時后，我覺得 Apache Oltu 的 文檔並沒有給我太多指導，因為有一些關鍵組件還沒有文檔化，但是一個例子讓我更好地了解了Oltu必須如何得到落實。 另一方面，通過Spring Security 的材料，我知道它仍然可以構建在非 Spring MVC 的 java 項目上。 但是在基於非 Spring 的項目中，Spring Security 的實現/教程的曝光有限。

另一種方法：

我想出了一種可能更穩定的架構，並且不會關心內部服務器的實現細節（已經使用 Jersey 實現的）。 在中間有一個專用於安全目的（授權、驗證、在自己的數據庫中存儲令牌等）的服務器，充當外部世界和內部服務器之間的網關。 它本質上充當中繼並路由呼叫，來回並確保客戶端對內部服務器一無所知，並且兩個實體僅與安全服務器通信。 我覺得這將是前進的道路

1. 替換為另一個安全提供程序只是意味着插入安全服務器實現並添加新的。
2. 安全服務器不關心內部服務器實現，調用仍將遵循 RESTful 標准。

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

Answer 1

Apache Oltu支持OpenID Connect，但它的架構很糟糕。 例如， OpenIdConnectResponse不應該的后代OAuthAccessTokenResponse因為開放ID連接反應並不總是包含一個訪問令牌。 此外，該庫奇怪地包含一個特定於 GitHub 的類GitHubTokenResponse 。

Spring Security很有名，但恐怕永遠無法支持 OpenID Connect。 有關 OpenID Connect 支持的大障礙，請參閱問題 619 。

java-oauth-server和java-resource-server是 Jersey + OAuth 2.0 的好例子，但它們使用商業后端服務Authlete 。 （我是它們的作者。）

OpenAM 、 MITREid Connect 、 Gluu 、 Connect2id和其他 OAuth 2.0 + OpenID Connect 解決方案列在 OpenID Foundation 的庫、產品和工具頁面中。

---

更新問題的更新

RFC 6749 （OAuth 2.0 授權框架）將授權服務器與資源服務器區分開來。 簡而言之，授權服務器是發出訪問令牌的服務器，資源服務器是響應伴隨訪問令牌而來的請求的服務器。

對於資源服務器， API Gateway是最近的設計模式之一。 Amazon、CA Technologies、IBM、Oracle 等公司提供 API Gateway 解決方案。 API 網關架構可能與您的想法很接近。 一些 API Gateway 解決方案以自己的方式驗證訪問令牌（因為解決方案自己發布訪問令牌），而其他解決方案只是將訪問令牌驗證委托給外部服務器（因為解決方案沒有發布訪問令牌的機制）。 例如， Amazon API Gateway是一個將訪問令牌驗證委托給外部服務器的示例，Amazon 將其命名為custom authorizer 。 有關自定義授權方的更多信息，請參閱以下內容。

• 在 Amazon API Gateway 中引入自定義授權方（AWS 博客）
• 啟用 Amazon API Gateway 自定義授權（AWS 文檔）
• Amazon API Gateway 自定義授權器 + OAuth （Authlete 文章）

如果授權服務器提供內省 API（例如RFC 7662 ），您可以使用有關訪問令牌的查詢信息，您的資源服務器實現可能能夠替換（插入和添加）授權服務器以相對容易地引用。

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

Answer 2

我認為，使用在 jersey 內部實現的 oauth 連接器要簡單得多！ 您是否考慮過使用 jersey 自己的 OAuth（已在 jersey 內部鏈接）服務器/客戶端？ https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest/security.html#d0e13146

請看一看：

16.3.2. OAuth 2 支持

希望有所幫助。 :)