# 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.

![](https://cdn.hashnode.com/uploads/covers/69722030e94f080c107ed87f/d5582c2f-81e0-4cdc-aca1-62c47bb320a2.png align="center")

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)

![](https://cdn.hashnode.com/uploads/covers/69722030e94f080c107ed87f/08fd297f-bcee-48fc-b07e-04acd9149208.png align="center")

* * *

## 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

1.  **"Keycloak is our auth"** — but no service validates JWTs; anyone with a forged cookie gets in.
    
2.  **Giant JWT** — stuffing every permission into the token; exceeds header limits and leaks data.
    
3.  **Same client for SPA and mobile** — different redirect URI and PKCE rules get mixed.
    
4.  **Prod realm cloned from dev** — with test users and wildcard redirect URIs still enabled.
    
5.  **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