我们拥有自主开发的专有用户管理和自主开发的Single Sign-on。(OpenID Connect当时还没有诞生(
我们的身份验证服务器和厚客户端位于专用网络中，无法访问互联网
任务是集成第三方厚客户端-其用户应根据我们现有的身份验证服务器进行身份验证
总体思路是使用现有的面向未来的框架，该框架提供标准身份验证接口(如Keyclock？(，并实现我们自己的OpenID Connect身份验证提供程序(或用于keyclock的用户存储SPI(
是否推荐使用keyclock和用户存储SPI的方式，或者是否有更好的方法？
正如您所说，这是满足您当前需求的好选择：
- 外部客户端使用现代OpenID连接流，例如桌面应用程序的OIDC
- 它连接到支持基于标准的端点的授权服务器
- Authorization Server具有对数据源的可扩展支持，并可能接触到您现有的用户数据源
例如，我工作的Curity支持多个数据源，如果有用的话，还有一个免费的社区版。
不过，任何满足相同要求的提供商都可以——我听说了一些关于Keycloft的好消息。
长期
然后逐步更新其他应用程序以使用现代OAuth和OIDC行为是有意义的。
在适当的时候，值得将授权服务器作为访问个人身份用户数据的唯一位置，并将存储移动到那里。请参阅这篇数据隐私文章，了解它的一些优点。
我可以担保Keycapture用户存储SPI方法。最近在一个项目中实现了这一点，并且运行得很好。对于任何现有的用户数据库，我强烈推荐它。
我在github上找到了一些您可以查看的示例源代码(尽管运行它需要一些修改(：https://github.com/mfandre/KeycloakSPI
我还写了一篇文章，总结了我使用Keycloft的发现，以防您对其他功能感兴趣：https://dev.to/kayesislam/keycloak-as-oidc-provider-42ip
它非常可定制。