java 将 Oauth 2.0 添加到基于 Jersey 的 RESTful 服务器

Adding Oauth 2.0 to Jersey based RESTful server

提问by vardhinisuresh27

I have a Jerseybased server that I want to secure with OAuth 2.0. There are two paths that I've seen as common:

我有一个Jersey基于服务器的服务器，我想用OAuth 2.0. 我认为有两条路径很常见：

• Oltu- Is compatible with Jersey and seems to be supported, although not as well as Spring Security. This 2012 questionseems to suggest this is the way to go, but I want confirmation on a 2016 context so I son't implement something not as well supported anymore.
• Spring Security- It seems to be very popular, but this path implies changing the server into a Spring based MVC. I don't know if that is something recommendable based on the benefits of using something as widely supported as Spring and the cost of the refactoring.

• Oltu- 与 Jersey 兼容并且似乎受支持，但不如 Spring Security。这个 2012 年的问题似乎表明这是要走的路，但我想确认 2016 年的上下文，所以我儿子不再实施不受支持的东西。
• Spring Security- 它似乎很流行，但这条路径意味着将服务器更改为基于 Spring 的 MVC。我不知道根据使用像 Spring 这样广泛支持的东西的好处和重构的成本，这是否值得推荐。

With support I mean a project that is in continous development, well established community with tutorials, materials and some libraries for clients (web, mobile, server) already available.

支持我的意思是一个持续开发的项目，完善的社区，提供教程、材料和一些客户端（网络、移动、服务器）库已经可用。

Which one is a stronger option? Is there another option or options?

哪个是更强的选择？还有其他选择吗？

In any case. Is there a good reference material or tutorial to start implementing this?

任何状况之下。是否有很好的参考资料或教程来开始实施？

---

---

UPDATE

更新

After few hours of reading and understanding about both the OAuth Providers I had mentioned, I feel Apache Oltu's documentationdid not guide me much as there are key components that aren't documented yet, but an examplegave me a better picture on how Oltumust be implemented. On the other hand, going through Spring Security's materialI got to know that it can still be built on a non-Spring MVC based java project. But there is a limited exposure of implementations/tutorials on Spring Security on a non-Spring based project.

在阅读和理解我提到的两个 OAuth Providers 几个小时后，我觉得 Apache Oltu 的文档并没有给我太多指导，因为有一些关键组件还没有文档化，但是一个例子让我更好地了解了Oltu必须如何实施的。另一方面，通过Spring Security 的材料，我知道它仍然可以构建在非 Spring MVC 的 java 项目上。但是在基于非 Spring 的项目中，Spring Security 的实现/教程的曝光有限。

Another approach:

另一种方法：

I came up with an architecture that might be more stable and would not care about the implementation details of the inner server(the one already implemented using Jersey). Having a server that is dedicated for security purpose (authorizing, authenticating, storing tokens in its own database, etc) in the middle that acts like a gateway between the outside world and the inner server. It essentially acts a relay and routes the calls, back and forth and ensures that the client knows nothing about the inner server and both the entities communicate with the security server only. I feel this would be the path to move forward as

我想出了一种可能更稳定的架构，并且不会关心内部服务器的实现细节（已经使用 Jersey 实现的）。在中间有一个专用于安全目的（授权、验证、在自己的数据库中存储令牌等）的服务器，充当外部世界和内部服务器之间的网关。它本质上充当中继并来回路由调用，并确保客户端对内部服务器一无所知，并且两个实体仅与安全服务器通信。我觉得这将是前进的道路

1. Replacing with another security provider just means plugging out the security server implemetation and adding the new one.
2. The security server cares nothing about the inner server implementation and the calls would still follow the RESTful standards.

1. 替换为另一个安全提供程序只是意味着插入安全服务器实现并添加新的。
2. 安全服务器不关心内部服务器实现，调用仍将遵循 RESTful 标准。

I appreciate your suggestions or feedbacks on this approach.

感谢您对此方法的建议或反馈。

回答by Takahiko Kawasaki

Apache Oltusupports OpenID Connectbut its architecture is bad. For example, OpenIdConnectResponseshould not be a descendant of OAuthAccessTokenResponsebecause an OpenID Connect response does not always contain an access token. In addition, the library weirdly contains a GitHub-specific class, GitHubTokenResponse.

Apache Oltu支持OpenID Connect，但它的架构很糟糕。例如，OpenIdConnectResponse不应是 的后代，OAuthAccessTokenResponse因为 OpenID Connect 响应并不总是包含访问令牌。此外，该库奇怪地包含一个特定于 GitHub 的类GitHubTokenResponse.

Spring Securityis famous, but I'm afraid it will never be able to support OpenID Connect. See Issue 619about the big hurdle for OpenID Connect support.

Spring Security有名，但恐怕永远无法支持 OpenID Connect。有关OpenID Connect 支持的大障碍，请参阅问题 619。

java-oauth-serverand java-resource-serverare good examples of Jersey + OAuth 2.0, but they use a commercial backend service, Authlete. (I'm the author of them.)

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

OpenAM, MITREid Connect, Gluu, Connect2id, and other OAuth 2.0 + OpenID Connect solutions are listed in Libraries, Products, and Toolspage of OpenID Foundation.

OpenAM、MITREid Connect、Gluu、Connect2id和其他 OAuth 2.0 + OpenID Connect 解决方案列在OpenID Foundation 的库、产品和工具页面中。

---

---

UPDATE更新问题的更新

RFC 6749(The OAuth 2.0 Authorization Framework) distinguishes an authorization serverfrom a resource server. In short, an authorization server is a server that issues an access token, and a resource server is a server that responds to requests which come along with an access token.

RFC 6749（OAuth 2.0 授权框架）将授权服务器与资源服务器区分开来。简而言之，授权服务器是发出访问令牌的服务器，资源服务器是响应伴随访问令牌而来的请求的服务器。

For a resource server, API Gatewayis one of the recent design patterns. Amazon, CA Technologies, IBM, Oracle and other companies provide API Gateway solutions. API Gateway architecture may be close to your idea. Some API Gateway solutions verify access tokens in their own ways (because the solutions issue access tokens by themselves) and other solutions just delegate access token verification to an external server (because the solutions don't have a mechanism to issue access tokens). For example, Amazon API Gatewayis an example that delegates access token verification to an external server, which Amazon has named custom authorizer. See the following for further information about custom authorizer.

对于资源服务器，API Gateway是最近的设计模式之一。Amazon、CA Technologies、IBM、Oracle 等公司提供 API 网关解决方案。API 网关架构可能与您的想法很接近。一些 API Gateway 解决方案以自己的方式验证访问令牌（因为解决方案自己发布访问令牌），而其他解决方案只是将访问令牌验证委托给外部服务器（因为解决方案没有发布访问令牌的机制）。例如，Amazon API Gateway是一个将访问令牌验证委托给外部服务器的示例，Amazon 将其命名为custom authorizer。有关自定义授权方的更多信息，请参阅以下内容。

• Introducing custom authorizers in Amazon API Gateway(AWS Blog)
• Enable Amazon API Gateway Custom Authorization(AWS Document)
• Amazon API Gateway Custom Authorizer + OAuth(Authlete article)

• 在 Amazon API Gateway 中引入自定义授权方（AWS 博客）
• 启用 Amazon API Gateway 自定义授权（AWS 文档）
• Amazon API Gateway 自定义授权器 + OAuth（Authlete 文章）

If an authorization server provides an introspection API (such as RFC 7662) that you can use query information about an access token, your resource server implementation may be able to replace (plug-out and add) an authorization server to refer to comparatively easily.

如果授权服务器提供内省 API（例如RFC 7662），您可以使用有关访问令牌的查询信息，您的资源服务器实现可能能够替换（插入和添加）授权服务器以相对容易地引用。

For an athorization server, gateway-style solutions are rare. It's because such a solution must expose all the functionalities required to implement an authorization server as Web APIs. Authleteis such a solution but I don't know others.

对于授权服务器，网关式的解决方案很少见。这是因为这样的解决方案必须将实现授权服务器所需的所有功能公开为 Web API。Authlete就是这样一个解决方案，但我不知道其他人。

回答by jeorfevre

I think, it's far simplier to use the oauth connectors that are implemented inside jersey itself! Have you considered using jersey own OAuth (already linked inside jersey) server / client ? https://jersey.github.io/documentation/latest/security.html#d0e12970

我认为，使用在 jersey 内部实现的 oauth 连接器要简单得多！您是否考虑过使用 jersey 自己的 OAuth（已在 jersey 内部链接）服务器/客户端？ https://jersey.github.io/documentation/latest/security.html#d0e12970

Please take a look to :

请看一看：

16.3.2. OAuth 2 Support

16.3.2. OAuth 2 支持

hope helped. :)

希望有所帮助。:)