When to Build vs Buy: Keycloak, Spring Authorization Server, and the Total Cost of Rolling Your Own
When to Build vs Buy
You have read 14 chapters on building an auth layer with Spring Security and Spring Authorization Server. Every chapter showed how to get it right and how it commonly goes wrong. The question you should be asking: should you build this yourself?
The answer depends on three variables: customization requirements, team expertise, and operational capacity.
The Tradeoff
| Factor | Build (Spring Authorization Server) | Buy (Keycloak, Auth0, Okta) |
|---|---|---|
| Customization | Unlimited. You own the code. | Limited to extension points and configuration. |
| Time to first login | Weeks to months | Hours to days |
| Ongoing maintenance | Your team | Vendor |
| Security patches | Your responsibility | Vendor’s responsibility |
| Multi-tenancy | Build it (CH8) | Varies by product |
| Token format control | Full control | Vendor-defined, some customization |
| Federation | Build integration | Usually built-in |
| Compliance | You prove it | Vendor provides certifications |
Neither option is universally correct. The choice is a function of your specific constraints.
The Build Trap
Teams choose to build because they want “full control.” Full control means full responsibility for:
- Every CVE in every dependency (Spring Security, Nimbus JOSE, Bouncy Castle)
- Key rotation (CH13), which requires operational procedures, monitoring, and on-call
- Token revocation (CH5-S2), which requires distributed state management
- Session security (CH7), which requires serialization hardening
- Password hashing upgrades (CH3), which require rehashing on login
- SAML integration (CH10-S2), which requires understanding XML signature wrapping attacks
If your team has one person who understands JWKS cache invalidation, that person cannot take vacation.
The Buy Trap
Teams choose to buy because they want to “focus on the product.” Vendor auth means:
- Your auth logic is in the vendor’s UI, not in your codebase. It cannot be code-reviewed, tested with your test suite, or deployed with your pipeline.
- Token claims are the vendor’s format. Changing claim structure requires vendor configuration changes, not code changes.
- Multi-tenant isolation depends on the vendor’s model. If the vendor’s tenancy model does not match yours, you build an adapter layer on top.
- Vendor lock-in. Migrating from Auth0 to Keycloak means migrating every user, every session, every integration, every client configuration.
What This Chapter Covers
Section 1: Decision variables. How to evaluate customization requirements, team expertise, and operational capacity. A framework for the build/buy decision that accounts for the long-term total cost.
Section 2: The ongoing maintenance cost. What “build” actually costs after launch: security patching, key rotation, dependency upgrades, and on-call burden. What “buy” costs after launch: vendor fees, integration maintenance, and migration risk.