我有一个基于Jersey的服务器，我想通过OAuth 2.0保护它。我认为有两条路径很常见：
支持我的意思是一个持续开发的项目，完善的社区，包括教程，材料和一些已经可用的客户端（网络，移动，服务器）库。
哪一个是更强的选择？还有其他选择吗？
无论如何。是否有一个很好的参考资料或教程来开始实现这个？
更新
经过几个小时的阅读和了解我提到的两个OAuth提供商之后，我觉得Apache Oltu的documentation并没有给我太多指导，因为有一些关键组件尚未记录，但是{{3}我更好地了解了Oltu必须如何实施。另一方面，通过example我知道它仍然可以构建在非基于Spring MVC的java项目上。但是，基于非Spring的项目对Spring Security的实现/教程的参与有限。
另一种方法：
我想出了一个可能更稳定的架构，并不关心内部服务器的实现细节（已经使用Jersey实现的）。拥有专用于安全目的的服务器（在其自己的数据库中授权，验证，存储令牌等），其作用类似于外部世界和内部服务器之间的网关。它本质上是一个中继，并来回路由呼叫，并确保客户端对内部服务器一无所知，并且两个实体仅与安全服务器通信。我觉得这将是向前迈进的道路
感谢您对此方法的建议或反馈。
答案 0 :(得分：2)
Apache Oltu 支持 OpenID Connect 但其架构很糟糕。例如，OpenIdConnectResponse不应该是OAuthAccessTokenResponse的后代，因为OpenID Connect响应并不总是包含访问令牌。此外，该库奇怪地包含一个特定于GitHub的类GitHubTokenResponse。
Spring Security 很有名，但我担心它永远无法支持OpenID Connect。有关OpenID Connect支持的重大障碍，请参阅Issue 619。
java-oauth-server 和 java-resource-server 是Jersey + OAuth 2.0的好例子，但他们使用商业后端服务 {{ 3}} 即可。 （我是他们的作者。）
列出OpenAM ， MITREid Connect ， Gluu ， Connect2id 以及其他OAuth 2.0 + OpenID Connect解决方案在OpenID Foundation的 Authlete 页面中。
<小时/> 更新更新问题
Libraries, Products, and Tools （OAuth 2.0授权框架）将授权服务器与资源服务器区分开来。简而言之，授权服务器是发出访问令牌的服务器，资源服务器是响应访问令牌附带的请求的服务器。
对于资源服务器， API网关是最近的设计模式之一。亚马逊，CA Technologies，IBM，Oracle和其他公司提供API网关解决方案。 API网关架构可能与您的想法很接近。一些API网关解决方案以自己的方式验证访问令牌（因为解决方案自己发出访问令牌），而其他解决方案只是将访问令牌验证委托给外部服务器（因为解决方案不具备发布访问令牌的机制） 。例如，RFC 6749是将访问令牌验证委托给外部服务器的示例，Amazon已将其命名为自定义授权程序。有关自定义授权程序的详细信息，请参阅以下内容。
如果授权服务器提供内省API（例如Amazon API Gateway Custom Authorizer + OAuth），您可以使用有关访问令牌的查询信息，则资源服务器实现可能能够替换（插入和添加）授权服务器比较容易地提到。
对于强化服务器，网关式解决方案很少见。这是因为这样的解决方案必须公开将授权服务器实现为Web API所需的所有功能。 RFC 7662是一个解决方案，但我不了解其他人。
答案 1 :(得分：0)
我认为，使用在球衣内部实现的oauth连接器要简单得多！ 您是否考虑过使用球衣自己的OAuth（已经在球衣内部链接）服务器/客户端？ https://jersey.github.io/documentation/latest/security.html#d0e12970
请看一下：
16.3.2。 OAuth 2支持
希望有所帮助。 ：）