选择一个OpenID Connect提供程序 [英] Choosing an OpenID Connect Provider
问题描述
我需要使用OpenID Connect在我的JAVA Web应用程序中实现SSO.我已经有使用SAML 2.0和WSO2作为身份提供者的SSO经验.
I need to implement SSO in my JAVA Web App with OpenID Connect. I already have experience in SSO with SAML 2.0 with WSO2 as Identity Provider.
我在客户端方面很清楚，并计划在Spring Security中实现相同的功能.
I am clear on the client part, and planning to implement the same with Spring Security.
我的问题是，为OpenID Connect构建我自己的身份提供程序是否有意义??出于某些原因，我不想使用任何第三方IDP(例如WSO2).
My question is, does it make sense to build my own Identity provider for OpenID Connect? For some reasons, I do not want to use any third party IDP (like WSO2).
如果是，是否有任何可以提供帮助的库?如果没有，我可以为OpenIDConnect使用的最好的IDP是什么?当然，WSO2在我的列表上居首位，因为我已经用WSO2实现了SAML SSO，并且它还支持OpenID Connect.
If yes, is there any library that can help? If no, what are the best IDP I can use for OpenIDConnect? Ofcourse, WSO2 is on top of my list because I have already implemented SAML SSO with WSO2 and it also supports OpenID connect.
任何经验或建议都是最欢迎的.
Any experience or suggestion is most welcome.
推荐答案
这个问题的答案并不那么简单.但是，我将尝试总结一些关键点，这将有助于做出决定.
An answer for this question is not that straightforward. But I will try to summarise some key points which will be helpful in making a decision.
- 成本和精力
您将必须自行开发和维护所有内容.这意味着要实施遵循
You will have to develop and maintain everything by yourself. This means implementing the specification (OpenID Connect) adhering to RFC6749. Adding to that you need to register clients, issue tokens, validate tokens and maintain token state (ex- issued refresh token). Indeed some libraries like Nimbus would come in handy.
如果您与第三方打交道，则必须严格遵守规范.取决于人才库，这可能是更高的开发成本和精力
If you are dealing with third parties you are bound to strictly follow specifications. And it could be a higher development cost and effort depending on the talent pool
- 维护和支持
任何内部开发都将附带支持和维护.错误修复，问题和新功能要求会随着时间的流逝而耗费大量成本，并可能会占用宝贵的开发时间
Any internal development will come with support and maintenance. Bug fixes, issues and new feature requirements will be costly over time and could involve valuable developer time
- 性能和可靠性
正如您已经提到的那样，实现自己的身份提供者并使之像任何现有产品一样具有挑战性.此外，身份提供者应该可靠.它必须足够安全以承受安全攻击(特别是如果您将其暴露在Internet上).实施时应从头开始考虑安全性(例如:用于令牌签名，访问令牌和刷新令牌熵的安全证书)
As you have mentioned, implementing your own identity provider and making it to perform as any existing product is challenging. Besides, identity provider should be reliable. It must be secure enough to sustain security attacks (specially if you are exposing it to internet). And implementation should be done with security in mind from ground up (ex:- Secure certificates for token signing, access token and refresh token entropy)
- 成本和精力
取决于提供者，它可以是免费的开放源代码或付费工具.而且，如果这是一款既定的产品，则实施工作会更少
Depending on the provider, it could be free and open source or paid tool. And if it is an established product there will be less implementation effort
- 维护和支持
现在这取决于服务协议.您可能需要支付支持费用.但是，您无需进行维护.产品可能缺少您期望的某些功能(例如- RFC7662 -令牌自省端点) .例如，MS Azure AD缺少自省端点.
Now this depends on the service agreement. You might have to pay for support. But you get rid of maintenance. A product might lack some features you expect it to have (ex- RFC7662 - token introspection endpoint). For example MS Azure AD lacks an introspection endpoint.
- 性能和可靠性
鉴于它是您购买的产品，或者是公开销售的产品，并且被许多商业产品使用，因此它们往往具有最佳性能.实际上，它们是由领域专家开发的(例如:经过所有规格检验的专业团队)，并且可能包括更高的可靠性.
Given that it's a product you purchase or available openly and used by many, commercial products tend to have optimum performance. And indeed they are developed by domain experts (ex:- A dedicated team who have gone through all the specs) and could include higher reliability.
PS-
不管所有这些考虑因素，都可能需要开发和维护内部身份提供者.如果是这种情况，则必须根据相关规范实施它并使其安全.希望这对您的决定有所帮助.
Regardless of all of these considerations, there could be a requirement to develop and maintain an internal identity provider. If that's the case you have to implement it according to related specifications and make it secure. Hope this helped with your decision.
这篇关于选择一个OpenID Connect提供程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
