初学者咨询IdentityServer4与Identity整合的核心疑问

Hey there! Let's break down your questions one by one—this is super common confusion when starting out with IdentityServer4 and ASP.NET Identity, so you're not alone.

1. What's the role of ASP.NET Identity's cookies and default template pages when IdentityServer4 issues tokens? #

IdentityServer4 doesn’t handle user authentication or user storage out of the box—it delegates that work to ASP.NET Identity. Here’s what those components do:

• Identity's Cookie: Once a user logs in via the Identity login page, ASP.NET Identity sets a cookie on the IdentityServer’s domain. This cookie maintains the user’s authenticated session with IdentityServer itself. So if the user needs to authorize another client app later, they don’t have to re-enter their credentials—IdentityServer checks the cookie and confirms the user is already authenticated. This is completely separate from the access token that gets issued to the client app.
• Default Template Pages: These are the pre-built UI for core user management flows: login, registration, password reset, email confirmation, etc. Since IdentityServer doesn’t provide its own UI, the Identity templates fill this gap to let you quickly implement the user-facing parts of authentication. Without these pages, you’d have to build your own UI from scratch to handle user sign-in/sign-up.

2. Why do SPA client examples still include these pages? Shouldn't auth/registration be done via APIs? #

This boils down to the secure OAuth2/OpenID Connect flow recommended for SPAs: the Authorization Code Flow with PKCE.

SPAs are "public clients"—they can’t securely store a client secret (any code in the browser is visible). For security, the standard flow requires redirecting the user to IdentityServer’s login page to authenticate. This way, the user’s credentials never touch the SPA—they’re entered directly on IdentityServer’s trusted domain. Once authenticated, IdentityServer sends an authorization code back to the SPA, which the SPA uses to fetch an access token.

The default pages are part of this standard, secure flow. That said, you can build custom API endpoints for registration/password reset (instead of using the template pages) if you want a fully headless auth experience. But official examples include the templates because they demonstrate the complete, out-of-the-box flow that most developers should start with.

3. How to deploy IdentityServer4 separately with the user database in a local network? #

This is a great security practice—keeping sensitive user data off the public internet. Here’s a practical breakdown:

• Step 1: Deploy IdentityServer as a standalone service: Create a dedicated IdentityServer4 project (integrated with ASP.NET Identity) and deploy it to a public-facing server (like an Azure App Service or AWS EC2 instance).
• Step 2: Connect to the local database: Configure the IdentityServer project’s connection string to target your internal network’s database (e.g., a SQL Server running on an internal server). For example:

  "ConnectionStrings": {
    "DefaultConnection": "Server=192.168.1.50;Database=IdentityDB;User Id=dbadmin;Password=yourSecurePassword;TrustServerCertificate=True"
  }
  

  Ensure the public IdentityServer server has network access to your local database—this can be done via a VPN tunnel, VPC peering (if using cloud), or by restricting database firewall rules to only allow traffic from the IdentityServer’s public IP.
• Step 3: Optional extra isolation: For even more security, move ASP.NET Identity’s user management logic to a separate internal API (only accessible on your local network). Then configure IdentityServer to call this internal API for user authentication/registration instead of directly connecting to the database. This keeps the database completely isolated from the public internet.
• Step 4: Update client apps: Point all your client apps (SPA, MVC, etc.) to the public IdentityServer’s URL as their authority endpoint.

Concrete examples are scarce, but the core idea is simple: let IdentityServer handle public auth requests, while it securely connects to your internal user database behind the scenes.

4. Why separate the user database from resource APIs? Are integrated IdentityServer4 and Identity considered a standalone API? #

Why separate the user database from resource APIs? #

• Security: If a resource API is compromised, attackers won’t get direct access to user credentials or personal data. The user database is only accessible to IdentityServer, which is built specifically with security best practices in mind.
• Single source of truth: Multiple resource APIs can share the same IdentityServer instance, so you don’t have to duplicate user data across every API. This makes user management (like password resets or role updates) consistent across all your apps.
• Separation of concerns: IdentityServer’s job is authentication/authorization—resource APIs should focus on business logic. Separating them lets you scale and update each independently (e.g., you can upgrade your API’s tech stack without touching IdentityServer).

Are integrated IdentityServer4 + Identity a standalone API? #

Absolutely! IdentityServer4 is inherently a standalone API that exposes standard OAuth2/OpenID Connect endpoints (like /connect/token, /connect/authorize, /connect/userinfo). When you integrate ASP.NET Identity into it, you’re adding user management capabilities to that API—either via the default UI pages or by building your own user management endpoints. You can even treat it as two logical parts:

1. The auth service (handling token issuance and authorization flows)
2. The user management service (handling sign-up, profile updates)
   But physically, they can live in the same deployed service unless you choose to split them for extra isolation.

内容的提问来源于stack exchange，提问作者user9152964