Identity Providers Are Not the Complete Solution
The myth
"We'll buy Okta / Auth0 / deploy Keycloak — then auth is done."
Identity providers (IdPs) and authorization servers solve a specific, hard problem: issuing tokens after authenticating a user and recording their consent. That is valuable. It is also roughly 30–40% of a real production auth story.
The rest is still your engineering, your UX, your threat model, and your operations.
What Keycloak / Okta / Auth0 actually give you
| Capability | Keycloak (self-hosted) | Okta / Auth0 (managed) |
|---|---|---|
| User directory (or federation hook) | Built-in + LDAP/AD | Built-in + federation |
| OIDC/OAuth endpoints | Yes | Yes |
| Admin UI for clients, scopes, roles | Yes | Yes |
| Social / enterprise IdP federation | Yes (brokers) | Yes (core product) |
| MFA policies | Yes | Yes (often stronger UX) |
| Hosted login pages | Themes (you customize) | Hosted, customizable |
| Compliance certifications | Your infra responsibility | Vendor SOC2/ISO etc. |
You are buying: a standards-compliant authorization server, user store or federation point, and token minting.
You are not buying: a finished application security layer.
What you still must build (the other 60–70%)
1. Application integration
Register every client (
client_id, redirect URIs, scopes)Configure Spring Security / your framework (covered in the Spring Security hands-on post)
Map IdP groups → application roles
Handle token validation on your APIs
2. UX beyond the login button
Landing pages, error states, account linking
"Session expired" and silent refresh behavior
Consent copy users actually understand
Branding that matches your product (Keycloak themes or Okta hosted pages)
3. Authorization inside your app
OAuth scopes ≠ your business permissions.
You need an authorization model (RBAC, ABAC, row-level security) in your services.
4. Session strategy
After OIDC login, what does the browser hold?
| Pattern | Pros | Cons |
|---|---|---|
| Server session + httpOnly cookie | Refresh token never in JS | Needs sticky sessions or shared store |
| BFF with cookie | Good for SPAs | Extra service to run |
| Tokens in SPA memory | Simple demo | XSS = token theft |
The IdP does not choose this for you.
5. API and microservice security
Validate JWTs (signature,
iss,aud,exp,nbf)Service-to-service auth (client credentials, mTLS)
Token propagation vs token exchange between services
Centralized policy (OPA, custom) vs per-service checks
6. Operational work
Keycloak (self-hosted):
HA deployment, database backups, upgrades
Realm configuration across environments (dev/stage/prod)
Secret rotation, TLS, network policies
Monitoring failed logins, brute force, token errors
Okta / Auth0 (managed):
Still: environment promotion, Terraform, rate limits, pricing tiers
Custom domains, email templates, support runbooks
Exit strategy / vendor lock-in considerations
7. User lifecycle
Registration, invite flows, password reset (if local users)
HR offboarding → disable user in IdP and revoke app sessions
Account merging, duplicate emails, guest users
8. Compliance and audit
Who accessed what, when — in your audit logs
Data residency (where Keycloak DB lives; Okta tenant region)
PII in JWT claims (minimize what you put in tokens)
Responsibility split (diagram)
Keycloak vs Okta vs Auth0 — how to think about the buy
| Factor | Keycloak | Okta / Auth0 |
|---|---|---|
| Cost model | Infra + your ops time | Per MAU / feature tier |
| Control | Full (you patch the server) | Limited to vendor features |
| Time to first login | Days (if you know K8s) | Hours |
| Customization | Deep (SPIs, themes) | Themed hosted pages |
| Best when | Cost at scale, on-prem, air-gap | Small team, fast ship, compliance via vendor |
None of them removes the your responsibility box above.
Anti-patterns we see in production
"Keycloak is our auth" — but no service validates JWTs; anyone with a forged cookie gets in.
Giant JWT — stuffing every permission into the token; exceeds header limits and leaks data.
Same client for SPA and mobile — different redirect URI and PKCE rules get mixed.
Prod realm cloned from dev — with test users and wildcard redirect URIs still enabled.
No logout story — IdP SSO session remains; user thinks they logged out.
Go deeper
Infrastructure as code
Treat realms, clients, and scopes as code (Keycloak Terraform provider, Okta Terraform, Auth0 deploy CLI). Manual admin UI clicks do not survive three environments.
Multi-region and DR
Keycloak: database replication, stateful session considerations. Managed IdPs: read their SLA and data residency docs — still your failover runbook for what happens when IdP is down (read-only mode? maintenance page?).
When to add an API gateway
Gateways can validate JWTs centrally. You still need fine-grained authorization in services — gateways are not a substitute.
What you should know after this post
[ ] You can list at least five things an IdP does not do for you
[ ] You separate OAuth scopes from application-level permissions
[ ] You have a realistic view of Keycloak ops vs Okta convenience