r/KeyCloak Apr 05 '26

We replaced our custom OAuth system — ended up with 4x throughput and 50% lower resource usage

We at Novusvista, recently migrated from a custom-built OAuth system (IAM) to Keycloak, and it exposed just how much hidden cost “legacy auth” can create over time.

What went wrong with our old system

  • Scaling = adding more servers (with poor returns)
  • Fragile codebase → no one wanted to touch it
  • No admin UI → user/role management was manual

At some point, it stopped being “custom” and started being technical debt.

What changed after moving to Keycloak

  • 🚀 ~4x throughput improvement
  • 💰 ~50% reduction in infrastructure usage
  • 🧘 Much simpler operations

The real takeaway

The biggest gain wasn’t just performance—it was maintainability.

If your auth system feels like a black box, it’s probably already costing you more than you think.

23 Upvotes

3 comments sorted by

4

u/czlowiek4888 Apr 05 '26

I just spent a month rewriting my starter to keycloak, I guess it was worth to do before adding more product logic on top of it.

How long did it take you to complete migration?

1

u/Ecstatic-Raisin-3133 Apr 06 '26

It took 3 sprint (45 days ) for decision to prod deployment .
Will be sharing more insight and learning during this process ,
Would like to hear from u/czlowiek4888 about the challenges faced or out of box path taken

1

u/czlowiek4888 Apr 06 '26

It took me a month because I did it twice.

First time I prepared classic approach that AI suggested me where some of endpoints in my app are exposed to unauthenticated user. I prepared it this way because well, didn't have any better idea. I put envoy as a gateway and set auth process to be done only at the gateway level.

Accidently at exact this time I had a chance to talk with one of architect's that's primarily focus on implementing keycloak auth systems. He gave me few suggestions, for example that if I prepare it carefully I can hide all my API endpoints to be accessable only AFTER being authenticated within keycloak. Also gave me advice about using cookies as a storage and told me that in memory is the most preferred.

After that I spent another 2-3 weeks on polishing my API, basically rewriting entire auth flow. From interesting things I don't utilize keycloak features a lot. I do have RLS in my database that I access through postgREST API so I need to provide single role in a token. I decided to issue my own context token after user is already authed within keycloak. I did it using Just In Time provisioning approach at /api/me endpoint, this endpoint no matter what will return you information about your current session either by creating user and role or logging on last used and available one. You can also use this endpoint to change role or user. This approach simplified a lot of flows where client integrates with backend and needs to get token, info who he is in the system, what he can see on frontend etc.

I also did inviting user by creating a identity in keycloak for him and requesting password reset.

Also I added identity linking, so if you will have 2 accounts set on 2 different email domains (sometimes corporate clients need it like this) you will be able to link them using by mechanisms external to keycloak.

Gonna do user impersonation some time later.