在设计 API 和 SDK 原型(prototype)时,我遇到了这个问题,并提出了几种可行的解决方案。我正在寻求一些高级架构的帮助。简而言之,可以保证 API 的某些使用应用程序会想要配置自己的身份验证提供程序。
我一直在思考的选项:
- 保持资源服务器和授权耦合,但找到某种方法将我的身份验证管理器中的身份验证提供程序之一中的身份验证委托(delegate)给客户端应用程序。
这听起来很有希望,直到我意识到在特定的用例中,实际上有必要甚至我的提供应用程序也不知道用户的凭据。
- 分离资源服务器,让每个使用应用程序负责提供授权服务器,并在向资源提供者注册使用应用程序时将这些端点设置为配置的一部分。
这感觉像是使用授权代码授权类型时通常所期望的令人不舒服的倒置。它还要求每个消费应用程序实现任何“默认”授权提供程序。
- 如果客户端未为其自己的授权服务器提供端点,则某种委托(delegate)授权服务器会回退到默认值。
这可能是一个很好的解决方案,但我不确定如何以“spring-security-oauth2”方式做到这一点,或者我是否必须实现一堆我自己的东西。
- 创建默认身份验证服务器,并可选择允许使用应用程序指向它们想要的任何身份验证服务器。
这似乎是可行的方法,因为它提供了大量的自定义功能。我关心的是,如何在资源服务器上强制执行某种注册表?如果身份验证服务器是批准消费应用程序的服务器,但我不想让任何消费应用程序实现自己的身份验证服务器,而只是其中一些应用程序。否则,不受信任的客户最终可能会批准自己!?
如果这影响任何指导,我的资源提供者将需要一个完全膨胀的 OAuth2Authentication 对象(其中包含用户详细信息和客户端详细信息)。
这张图片主要解释了我正在谈论的内容,除了我想要多个授权服务器并希望将其留给使用应用程序来决定指向哪个授权服务器。我如何在资源服务器端检查代理请求的授权服务器是否是经过批准的授权服务器?
附录:
我查看了用于此自定义身份验证案例的现有实现,我想我们只是从他们的 session 中读取由他们自己的登录服务设置的 token ,并每次都构建他们的用户。这种定制是一个问题,因为我们正在从提供者方面删除定制,以便在消费应用程序中处理定制。因此,我正在寻找解决方案,以便消费应用程序可以定义自己的身份验证方式,甚至可以向用户提供提供的应用程序不会持续存在(这使我认为它可能需要成为一个完整的身份验证服务器)。
话虽这么说,这似乎是一个潜在不可持续的倒置模型(恕我直言,提供商应该是用户和授权的维护者,而不是消费应用程序)。因此,我可能会建议进行更加面向业务的更改。最佳答案
我相信我终于想出了一种安全且可维护的方法来解决这个问题。
- 允许使用应用程序选择向授权服务器注册身份验证回调。
- 要求代表用户从该应用程序向授权服务器发出的传入授权请求包含 token ,该 token 应由使用应用程序存储,作为引用主动引发 API 调用的用户的一种方式。
- 当授权服务器从已注册这些回调之一的应用程序收到授权码请求时,会 POST 到该应用程序的已注册身份验证回调,并在请求中包含使用方应用程序提供的 token 。<
- 消费应用程序应获取已发布到其注册身份验证回调的 token 并查找相应的用户,并返回包含完整用户对象的响应,提供应用程序应代表该对象进行操作(或者某种错误代码,如果 token 无效)。
- 授权服务器随后应生成授权码并返回随授权码请求一起提交的回调 uri。这意味着我们回到了原始问题图中的步骤 4 的正轨。其余步骤可以按原样执行。
还有一个问题是如何实现这一点,以尽可能多地利用 spring-security-oauth2 框架,同时仍然实现此扩展。
关于spring - 如何使用 spring-security-oauth2 支持消费应用程序可配置身份验证提供程序,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27749526/