Choosing an OpenID Connect Provider

Question

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.

I am clear on the client part, and planning to implement the same with Spring Security.

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).

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.

Answer 1

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.

Implementing in-house identity provider

• Cost and effort

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

• Maintenance and support

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

• Performance and reliability

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)

Using a third party product

• Cost and effort

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

• Maintenance and support

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.

• Performance and reliability

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.

P.S -

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.