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

我有一个基于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的实现/教程暴露有限。

另一种方法：

我想出了一个架构，可能会更稳定，不会在乎内部服务器（使用新泽西州已经实施的一个）的实施细则。有一个专门用于安全目的的服务器（在其自己的数据库中授权，认证，存储令牌等）在中间扮演着外部世界和内部服务器之间的网关的角色。它本质上是一个中继，并且来回路由这些调用，并确保客户端对内部服务器一无所知，并且这两个实体只与安全服务器进行通信。我觉得这将是前进的道路，因为

替换与另一个安全提供商只是意味着插入安全服务器实施并添加新的。
安全服务器不关心内部服务器的实现，并且调用仍然遵循RESTful标准。

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

来源

2016-05-04 vardhinisuresh27

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

请看一看到：

16.3.2。 OAuth的2支持

希望帮助。 :)

来源

2016-05-04 15:54:31 jeorfevre

Jersey的OAuth 2支持仅适用于客户端。 –

Takahiko川崎，我一直在阅读这个问题，我不认为vardhinisuresh27要实现是自己的oauth内部机制。为什么不使用已经开发和提供的？ – jeorfevre

如果vardhinisuresh27想要实现OAuth 2.0 _client_，则可以使用Jersey的OAuth 2.0支持。另一方面，如果他想要一个OAuth 2.0服务器，我必须指出，泽西岛不支持这种情况。因为他提到了Oltu和Spring Security，它们都是OAuth 2.0服务器解决方案，所以我认为他想实现OAuth 2.0服务器。 –

阿帕奇Oltu支持OpenID Connect但其结构是不好的。例如，OpenIdConnectResponse不应该是OAuthAccessTokenResponse的后裔，因为ID连接反应并不总是包含一个访问令牌。此外，图书馆古怪包含GitHub的特定类，GitHubTokenResponse。

Spring Security是有名的，但恐怕它永远无法支持OpenID Connect。有关OpenID Connect支持的大障碍，请参见Issue 619。

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

OpenAM，MITREid连接，GLUU，Connect2id，和其他的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是代表访问令牌验证到外部服务器，亚马逊已经任命定制授权一个例子。有关自定义授权人的更多信息，请参阅以下内容。

Introducing custom authorizers in Amazon API Gateway（AWS博客）
Enable Amazon API Gateway Custom Authorization（AWS文件）
Amazon API Gateway Custom Authorizer + OAuth（Authlete文章）

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

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

来源

2016-05-04 19:41:51

@ vardhinisuresh27我更新了我的答案，以解决您的其他问题。 –

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

回答

相关问题