为何需在IdentityServer 4登录而非MVC应用？登录重定向疑问

Great question! It’s totally reasonable to want to avoid those redirects—they can feel clunky and add extra latency. Let’s break down why IdentityServer 4 is designed this way, and also cover whether there’s a path to align with your preference.

1. Core Purpose: Single Sign-On (SSO) & Centralized Identity Management #

IdentityServer’s biggest value proposition is enabling SSO. Think about it: if you ever add another app (a mobile app, a SPA, another MVC site) that needs to authenticate users, they only log in once via IdentityServer and get access to all your trusted apps. If you handled login directly in your MVC app, every new app would need its own login system, forcing users to remember multiple credentials and you to manage identity rules across every project.

Centralized management also makes security and maintenance easier:

• Update password policies, enable multi-factor authentication (MFA), or revoke a user’s access? Do it once in IdentityServer, and all connected apps automatically respect those changes.
• No need to replicate login logic, password hashing, or security checks across every app you build.

2. Security & Compliance Best Practices #

Identity authentication is a high-stakes security problem, and IdentityServer is built from the ground up to follow OAuth2/OpenID Connect standards and security best practices. Here’s why handling login in your MVC app is riskier:

• You’d have to implement anti-CSRF protections, secure password storage, token validation, and more from scratch—easy to miss critical details that lead to vulnerabilities.
• In regulated industries (finance, healthcare, government), centralized identity management is often a compliance requirement. It simplifies audit trails and ensures consistent identity controls across your ecosystem.

3. The Trust Model Behind Tokens #

When your MVC app gets user identity data from IdentityServer, it’s receiving cryptographically signed tokens (ID Tokens, Access Tokens). For your MVC app to trust these tokens, they need to come from a trusted, dedicated identity provider (IdP)—which is IdentityServer.

If you logged users in directly in your MVC app, you’d either:

• Have to turn your MVC app into an IdP itself (defeating the purpose of using IdentityServer), or
• Create tokens that other apps (if you ever build them) won’t trust, since they’re not signed by a centralized, trusted source.

The redirect flow is part of the OpenID Connect authorization code flow—it’s how the MVC app and IdentityServer securely verify the user’s identity and exchange tokens without exposing sensitive credentials.

What If You Really Want to Keep Login in Your MVC App? #

If you don’t need SSO, centralized identity management, or the security guardrails IdentityServer provides, you can skip IdentityServer entirely. Use ASP.NET Core Identity directly in your MVC app to handle login, registration, and identity management—this keeps everything within your app with no redirects.

If you still want to use IdentityServer but minimize redirect friction:

• Optimize the IdentityServer login page (enable caching, compress assets) to reduce load time.
• Avoid embedding the login page in your MVC app (this breaks security best practices and violates OpenID Connect specs—don’t do this in production).

At the end of the day, the redirect is a tradeoff for the security, scalability, and SSO capabilities that IdentityServer provides. If those benefits don’t apply to your specific use case, going with a standalone identity system in your MVC app makes perfect sense.

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