How We Migrate Legacy Authentication OAuth 1.0 Using JWT And Redis
It’s the fourth part of a series of our cloud migration journey
Redis is an essential part of every software application, and today we’ll look at how we used it for authentication and authorization in our application.
For authentication, our legacy software uses OAuth 1, which most of the time travels to the database for verification. We continued to use caching, but it wasn’t performing as well as we had intended, and we were transitioning from a monolithic to a microservice design. As a result, we require a solution that is simpler, modern, and scalable.
Because our OTT application has a variety of clients and partners, each has its API credentials. The header identifies which API client is sending the request, allowing us to know who is sending it.
I’m familiar with JWT from previous experience and considering the present business use case, it was an excellent pick for us.
Flow
- We build a client and a secret, which we store in Postgres for persistent storage and Redis for caching.
- For every request we validate API client and we check in Redis. Redis is now our central database for validating and authorising requests across all microservices.
- JWT has one flaw as well. If a token hasn’t expired and the user is logged out, it’s still valid. To get around this, we check if the token exists in Redis.
We want our authentication to take less than 1 millisecond for 100k RPS, therefore we optimised the code to reduce the amount of Redis calls required to get the client and secret for each request and store it in memory.
We also ran various benchmarks with different versions of Azure Redis, Azure Redis Enterprise Edition, and Azure Redis with the OSS Cluster, before settling on Redis Labs’ Azure Enterprise Edition.
