No one really does authentication or identity brokering anymore without leveraging an external library or service. An Identity Broker is an intermediary service that connects your application to various other identity providers like Google, Microsoft, Active Directory etc. In order to migrate an application that had its own legacy in-house authentication component, I evaluated a few solutions that are popular now - in this blog post, I pen down the pros and cons of each, and why I chose KeyCloak over the other options. I then show how to connect KeyCloak to Okta.
IAM (Identity & Access Management) solutions come in various forms - as libraries to be added into your code base and extended upon with code (like IdentityServer), as SaaS offerings by companies like Okta, and as standalone deployable products like KeyCloak. The choice is yours. If you want something hassle free, go with cloud hosted services, at the cost of, well, cost. Most of these cloud services charge you based on number of distinct users logging in each month. They generally have a free or very cheap initial level to keep the barrier of entry low. But as the number of users increases, the cost also increases heavily. With a cloud service, you also add an extra point of failure for your application.
The third option is KeyCloak - IAM as a product. I was surprised I had not seen this earlier, I had always used a library for authentication. I am not aware if there are other similar products out there, please let me know in comments if there are any. It is free and open source, and highly customizable, and even has a decent UI. You can deploy it along with your own services and thus avoid new failure points. For example, I run it as a service in kubernetes, has its own SQL database, and both the compute and database are covered under a disaster recover plan that is the same as that for my application. Redhat has a paid version that includes support. It supports connecting to any IdP that is over a standard protocol like OpenID or SAML.
It can also federate user accounts in external directories like LDAP/AD.
Other great things about this - their documentation is really good, the HTML and CSS are customizable and it is easy to automate the creation of 'realms' and 'users' - I will write a separate post on automation using Azure DevOps.
To show how flexible it is to work with KeyCloak, let's take a look at the following integration:
Here, my webapp connects to KeyCloak, which needs to know how to redirect the user to Okta. Okta needs to know to redirect to Azure AD, and once the user is authenticated, Okta needs to know how to redirect back to KeyCloak. We will specifically talk about the KeyCloak-Okta connection only here. From the perspective of Okta, KeyCloak is a server side webapp, even though my webapp is a SPA. So we create a new app integration in Okta as below:
In the next screen, you need to provide a way to connect back to KeyCloak for both sign in and sign out redirects. You get this from KeyCloak when you configure the OIDC provider in Add Provider screen. Note the authorization server URL from Okta :
Paste this URL into the "Import from URL" textbox at the bottom of the Add Identity Provider Screen and click on Import:
This automatically identifies the required URLs. Now the main part of connecting the two:
Take the Redirect URL from keycloak and put it in Okta (Sign-out uri is same as login, but with a /logout_response added at the end)
Take the client id and client secret from Okta and put it in keycloak.
That's it! AD-Okta integration is well documented, and you can now use keycloak npm to easily handle the login and logout redirects from your SPA app.