Transitioning between authorization solutions is often a strategic move. Here we dive into the journey from Spring Authorization Server to Keycloak – two prominent players in the realm of identity and access management (IAM)
In 2020, Spring decided to deprecate "Spring Security OAuth" and announced an End-of-Life as end of May 2022. Back then, we started to think about an alternative to Spring. Although Spring announced back the return of Spring Security OAuth in Spring Authorization Server, the earlier is poor in features compared to Keycloak and its strong community. There could be many reasons driven by evolving security needs, scalability requirements, or for enhanced user experience to device for Keycloak.
Starting on the journey of transitioning from Spring Authorization Server to Keycloak is quite the undertaking, isn't it? 👀
But fear not, because I'm here to guide you through it! Recognizing the complexity of this move, I've decided to break it down into a series of articles, tackling each challenge along the way to ensure a smooth transition 🤝.
You might be wondering, why go through all this trouble if both are based on Auth2.0 standard? Well, despite the popularity of both Spring Authorization Server and Keycloak, detailed migration guides are surprisingly scarce. Each has different URLs, slightly difference in payload and the most important is the missing OpenID Connect (OIDC) in Spring Security OAuth which makes it harder to have the easy move you expect (e.g. using the default OIDC broker in Keycloak). That's where I come in – to provide you with a roadmap for success 👨🎓
Before we dive into the nitty-gritty details, let's make sure we're all on the same page. Understanding the basics of Identity and Access Management (IAM) is key. If terms like OAuth 2.0, authorization code flow, refresh token flow, and OpenID Connect (OIDC) sound like a foreign language to you, Just Google it. I am sure you'll find many resources for that. Building a solid understanding of these fundamentals will set the stage for a smoother migration journey. So, are you ready to get started? Let's do this! 🚀
Getting started
When it comes to tackling big tasks like this, I'm a big advocate for starting small and taking things one step at a time. This approach allows for learning from mistakes and making necessary adjustments along the way – it's all about that iterative process!
So, where do we begin?
Well, let us assume the current authorization server as simple as below:
The authorization server depends on two services, one for the user profile and another that stores the user credentials.
It's crucial to maintain a seamless user experience during migration. Users shouldn't need to re-login for new tokens from Keycloak or transfer data between data sources. This applies to resource servers too.
To ensure this, we need a traffic-controlling gateway and careful management of client migration. Instead of big moves, migrating client by client minimizes the risk of full outages in case of failures.
Based on that, Here is -in abstract- the new design:
In below articles, I'll cover some topics to achieve a smooth migration:
- Brokering non-OIDC OAuth 2.0 identities to solve absence of OIDC in Spring Security OAuth.
- Authorization Code flow migration and retain OAuth Clients and Resource Servers Untouched
- Refresh token migration and the same, OAuth Clients untouched.
- The migration of refresh token grant type can't be completed without utilizing the Token Exchange in our OAuth 2.0 custom identity provider described in the above article.
Beside that, there are some selected topics where I found it very useful to share.
- Optimized Keycloak build: Creating a suitable Docker file for Keycloak based on your setup
- Ensure Keycloak stays within the internal network while exposing only its APIs publicly
- Use maven shade plugin to include SPIs third-party libraries in the same SPI JAR
- Use Terraform to configure a custom identity provider
- For Datadog users, A guide to integrate Keycloak with Datadog
I hope it will help you!
Top comments (0)