ASP.NET Core Identity is powerful but heavy. Learn when to use it, when not to, how it impacts scaling, and how misuse leads to auth complexity and production incidents.
On this page
Identity Is a Full Identity System, Not Just Login
ASP.NET Core Identity provides:
- user store
- password hashing
- lockout
- email confirmation
- two-factor support
- token generation
- role management
It is a complete identity management framework.
Production rule:
Use Identity when you need to manage users yourself. Do not use it blindly for API-only services.
Real Production Incident
Symptoms:
- High latency on login endpoints.
- Unexpected database load.
- Lockout logic inconsistent across instances.
- Complex auth bugs after scaling horizontally.
Root cause:
- Identity configured with default settings without understanding persistence model.
- Heavy synchronous operations during login.
- User store not optimized or indexed properly.
- Custom extensions bolted on top without clear boundaries.
Identity was used as a black box, not a system component.
Symptom → Cause → Diagnosis → Fix
Symptom:
- login performance degradation
- database contention on AspNetUsers tables
- inconsistent lockout behavior
- auth flows hard to debug
Cause:
- not understanding Identity’s schema and flows
- no proper indexing on normalized columns
- mixing Identity with external token validation poorly
- extending Identity in ad-hoc ways
Diagnosis:
- inspect database query plans for login operations
- review Identity configuration (password hashing iterations, lockout thresholds)
- audit custom UserManager/SignInManager overrides
- measure login endpoint latency separately
Fix:
- use Identity only when needed
- optimize user store (indexes, constraints)
- isolate Identity logic from domain logic
- consider external identity provider for complex scenarios
When to Use ASP.NET Core Identity
Use Identity when:
- you manage users internally
- you need password-based login
- you require email confirmation, password reset
- you need built-in 2FA and lockout support
- you control the user database schema
It is well-suited for:
- SaaS apps with internal user accounts
- admin panels
- B2C apps without external IdP
When NOT to Use Identity
Avoid Identity when:
- your service is API-only and trusts external IdP (OIDC, OAuth2)
- you do not manage user passwords
- authentication is entirely delegated
- you want stateless token validation only
In these cases:
- use JWT validation only
- avoid unnecessary user store and schema complexity
Production rule:
Do not embed a full identity system in every microservice.
Anti-Pattern: Identity in Every Service
Each microservice:
- has its own AspNetUsers table
- manages roles locally
- performs login
This leads to:
- duplicated user state
- synchronization problems
- complex migrations
- security inconsistencies
Correct pattern:
Centralize identity in one service or external provider.
Other services validate tokens and enforce authorization.
Scaling Considerations
Identity is database-backed.
At scale:
- login bursts can cause DB pressure
- lockout counters can cause write contention
- token storage (if used) can grow
Mitigations:
- proper indexing (NormalizedUserName, NormalizedEmail)
- short-lived access tokens after login
- avoid frequent writes to user record for trivial actions
- use caching carefully (but do not cache sensitive auth state incorrectly)
Production rule:
Login endpoints are high-risk and must be load tested.
Password Hashing and Cost
Identity uses secure password hashing (PBKDF2 by default).
High iteration counts increase security but increase CPU cost.
Balance:
- strong hashing cost
- acceptable login latency
Monitor:
- login latency
- CPU utilization during peak login events
Do not:
Lower hashing cost without security review.
Security Notes
- Always require HTTPS.
- Enforce strong password policies appropriate for risk.
- Enable account lockout with sane thresholds.
- Protect against user enumeration (uniform responses for login failures).
- Do not expose whether email exists.
If integrating with JWT:
- issue tokens only after successful Identity authentication.
- validate tokens strictly in downstream services.
Operational Notes
Monitoring:
- track login success/failure rates
- alert on spikes in failed login attempts (possible attack)
- monitor lockout rates
Rollout:
- Changes to password policy or hashing cost are breaking for users.
- Canary changes carefully.
- Test migrations that affect AspNetUsers schema.
Rollback:
- If auth regression blocks all logins, rollback immediately.
- Maintain admin break-glass access.
Governance:
- Document identity flows clearly.
- Keep identity code separate from business logic.
- Avoid uncontrolled customization of Identity internals.
Checklist
- Identity used only where user management is required.
- External IdP preferred for API-only or distributed systems.
- Identity tables properly indexed.
- Login endpoints load tested.
- Password hashing cost balanced and monitored.
- Lockout and enumeration protections configured.
- Identity changes are canaried and rollbackable.
- Identity logic isolated from core business domain.
