OpenID Connect 1.0 is a simple identity protocol on top of the OAuth 2.0 protocol. It allows applications to verify the identity of the end-user based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner. It is built on OAuth 2.0 using architectural principles from OpenID 2.0. The OpenID protocol authenticates the identity of a user and the OAuth protocol performs the authorization of that user. It has two components named OpenID Provider (OP) and OpenID Relying Party (RP).
OpenID Connect overcomes the limitations of OpenID 2.0 where RPs could only be Web pages and not native applications (non-browser based applications) and relied upon XML. The OpenID Connect protocol uses the JSON data format to exchange security data and provides a RESTFul HTTP API.
The typical OpenID Connect (OIDC) message flow between an OP and RP is shown in the figure below. Here, an end-user attempts to login to a web page, and the application server serving the web page serves as the RP, which delegates the responsibility of verifying the user identity and authorization data to the OP. The OP identifies the end-user and in turn optionally checks with that user regarding what information they will allow the OP to share with the RP. The OP talks to a local or a remote user repository such as an LDAP back-end to gather all the authorization and profile data about the end-user. Based on the user response, the OP shares that information and also authenticates the user to the web page by providing an Identity and Access token to the RP for that user.
A real world example of OpenID Connect usage is PayPal, a widely used Online Payment Company that implements OpenID Connect. PayPal shares personal information about users, such as mailing, billing, addresses, phone numbers, etc. to Online Commerce websites where PayPal payment is accepted.
Today, the OpenID Connect standard has become so popular that social web sites like Google, Facebook, and Yahoo have implemented it. They provide the OpenID Connect OP implementation so that applications can register with them as RPs, in order to authenticate users, who have logins to these social web sites. You can learn more about OpenID Connect here.
IBM WebSphere Liberty Profile provides a full implementation of the OpenID Connect standard. As Liberty runs in various cloud or private environments, one can easily build the OP and RP microservices for securing applications.
To understand the strengths and weaknesses of the OpenID Connect implementation in WebSphere Liberty, I compared it to the OpenID implementation in open source Tomcat and WildFly servers. Note that before starting this study I was a newbie to OpenID Connect security standard and was equally novice about the capabilities in WebSphere Liberty, Tomcat and WildFly for this standard. I first researched WebSphere Liberty and found that it provides a simple and easy to use implementation for the standard. Next, I researched Tomcat and it natively does not provide an OpenID Connect implementation but there are open source OpenID Connect projects that work with Tomcat – the most popular being MitreID Connect. Last in the research was WildFly server and it has an open source OpenID Connect implementation named Keycloak.
For this comparison, I implemented OpenID Connect security in an online banking application to login and logout users from the bank website. I did this implementation using WebSphere Liberty OpenID Connect feature, Tomcat with MitreID Connect and WildFly with Keycloak. The figure below shows the implementation times to implement OpenID Connect for each of the servers. With Liberty I was able to implement it in 47 minutes. With Tomcat and WildFly I spent over 600 minutes and was still not able to fully implement it in this time frame.
The reasons why I was able to implement quickly with WebSphere Liberty profile and not able to implement with Tomcat and WildFly are as follows:
- Liberty Server uses a single xml file to configure both the RP and the OP. With Tomcat and WildFly there are many XML files one needs to edit to configure the RP and OP as seen in the figure below. It becomes quite cumbersome to edit several XML files leading to human errors and unmanageable configurations.
- MitreID Connect uses the Spring Framework to implement OpenID Connect. One needs to have deep skills in Spring to integrate and implement with Tomcat. The Spring Framework jars need to be manually added to the RP and OP. Furthermore, the documentation for MitreID Connect is very poor and their user forums are slow in responding to queries.
- Keycloak comes integrated with WildFly for the OP, however for the RP it provides an adapter that needs to be manually integrated. This integration process is labor intensive and involves configuring several files. The documentation for Keycloak is also poor and their user forums are also slow in responding to queries.
In the figure below I captured the seven easy steps one needs to perform to implement OpenID Connect RP and OP in Liberty Profile. Note that all the changes to implement the RP and OP microservices are done in one single server.xml in the RP and OP Liberty Profile servers.
Being new to the OpenID Connect security, Liberty Server was the guinea pig for me to understand the OpenID Connect standard. However, the above simplicity of implementing OpenID Connect in WebSphere Liberty made it easy to understand the OpenID Connect security standard. As Tomcat and WildFly were follow-on servers I researched after researching Liberty Profile, I already had a relatively good understanding of the OpenID Connect standard. Although, I started with a good knowledge of OpenID Connect, its implementation was quite complex in Tomcat and WildFly and with limited documentation and forum support I could not completely implement it in these servers.
This OpenID Connect OP and RP microservices implementation comparison revealed that it is much faster and easier to implement OpenID Connect microservices in Liberty Profile than it is in Tomcat and WildFly.
You can find an overview comparison of security capabilities in Liberty, traditional WebSphere, JBoss, Tomcat and WebLogic here: “Security comparison: WebSphere, Tomcat, JBoss, WebLogic“.
You can download WebSphere Liberty profile and WebSphere Developer Toolkit from here. And remember – WebSphere is free for development and free for limited scale production!