选择 OpenID Connect 提供程序答案

【问题标题】：Choosing an OpenID Connect Provider选择 OpenID Connect 提供程序
【发布时间】：2017-12-12 02:57:35
【问题描述】：

我需要使用 OpenID Connect 在我的 JAVA Web 应用程序中实现 SSO。我已经有使用 SAML 2.0 和 WSO2 作为身份提供者的 SSO 经验。

我对客户端部分很清楚，并计划在 Spring Security 中实现相同的功能。

我的问题是，为 OpenID Connect 构建自己的身份提供程序有意义吗？出于某些原因，我不想使用任何第三方 IDP（如 WSO2）。

如果是，是否有任何图书馆可以提供帮助？如果不是，我可以为 OpenIDConnect 使用的最佳 IDP 是什么？当然，WSO2 是我的首选，因为我已经使用 WSO2 实现了 SAML SSO，并且它还支持 OpenID 连接。

欢迎任何经验或建议。

【问题讨论】：

【解决方案1】：

这个问题的答案并不那么简单。但我会尝试总结一些有助于做出决定的关键点。

实施内部身份提供者

您必须自己开发和维护所有内容。这意味着实施遵循RFC6749 的规范（OpenID Connect）。除此之外，您还需要注册客户端、颁发令牌、验证令牌并维护令牌状态（已发布的刷新令牌）。事实上，像Nimbus 这样的一些库会派上用场。

如果您与第三方打交道，您必须严格遵守规范。根据人才库的不同，这可能是更高的开发成本和工作量

任何内部开发都将提供支持和维护。随着时间的推移，错误修复、问题和新功能要求的成本会很高，并且可能需要宝贵的开发人员时间

正如您所提到的，实现您自己的身份提供程序并使其像任何现有产品一样运行具有挑战性。此外，身份提供者应该是可靠的。它必须足够安全以承受安全攻击（特别是如果您将其暴露在互联网上）。实施时应该从头开始考虑安全性（例如：- 用于令牌签名、访问令牌和刷新令牌熵的安全证书）

根据提供商的不同，它可以是免费的、开源的或付费的工具。如果它是一个成熟的产品，那么实施工作就会减少

现在这取决于服务协议。您可能需要支付支持费用。但是你摆脱了维护。产品可能缺少您期望它具有的某些功能（例如-RFC7662 - 令牌自省端点）。例如，MS Azure AD 缺少自省端点。

鉴于它是您购买或公开提供并被许多人使用的产品，商业产品往往具有最佳性能。事实上，它们是由领域专家开发的（例如：- 一个已经完成所有规范的专门团队），并且可能具有更高的可靠性。

附言-

无论所有这些考虑因素如何，都可能需要开发和维护内部身份提供者。如果是这种情况，您必须根据相关规范实施它并使其安全。希望这对您的决定有所帮助。

【讨论】：