能否将Identity Server 4作为独立API/服务运行，分离登录注册等功能？

Absolutely! This setup isn’t just possible—it’s actually a best practice for building scalable, maintainable auth systems. IdentityServer4 was designed to be modular, so you can easily decouple the core authorization logic from user-facing UI flows like login, registration, and password reset. Let me walk you through how this works and what you need to do.

Core Idea #

Think of IdentityServer4 as your single source of truth for all authorization decisions: it issues tokens, validates client requests, and manages OAuth2/OpenID Connect flows. Your standalone Web app takes care of everything users interact with—rendering login forms, handling registration submissions, sending password reset emails, etc. The two work together via standard OpenID Connect protocols.

Key Implementation Steps #

1. Configure IdentityServer4 as a standalone service #

You’ll want to strip out any built-in UI components and focus on core authorization functionality:

• Skip adding quickstart UI packages or calling AddIdentityServerUI() in your setup.
• Define your clients (register your standalone Web app as a client here, using the authorization_code grant type with PKCE—this is the most secure flow for web apps).
• Set up identity resources (like openid, profile) and API resources as needed for your system.
• Connect to your user store (this can be the same database your Web app uses, e.g., via ASP.NET Identity or a custom store) so IdentityServer can validate user credentials and fetch claims.
• Critical: Configure IdentityServer to redirect to your Web app’s UI for login/logout. In your IdentityServer options:

  services.AddIdentityServer(options =>
  {
      options.UserInteraction.LoginUrl = "https://your-web-app-domain.com/login";
      options.UserInteraction.LogoutUrl = "https://your-web-app-domain.com/logout";
      options.UserInteraction.ErrorUrl = "https://your-web-app-domain.com/error";
  })
  // Add your clients, resources, and user store here
  

2. Build your standalone Web app for user management #

This app will handle all user-facing auth flows:

• Create login, registration, password reset, and profile pages tailored to your brand/UX needs.
• When a user tries to access a protected resource (or when IdentityServer redirects them), your app will handle credential validation using your user store (e.g., ASP.NET Identity’s SignInManager).
• After successful login, redirect the user back to IdentityServer’s callback endpoint (the returnUrl parameter that IdentityServer passes to your login page). IdentityServer will then issue the appropriate tokens and redirect the user to the original protected resource.

Example login action in your Web app:

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Login(LoginViewModel model, string returnUrl = null)
{
    returnUrl ??= Url.Content("~/");
    
    if (ModelState.IsValid)
    {
        var result = await _signInManager.PasswordSignInAsync(model.Email, model.Password, model.RememberMe, lockoutOnFailure: false);
        if (result.Succeeded)
        {
            // Redirect back to IdentityServer to complete the auth flow
            return Redirect(returnUrl);
        }
        if (result.RequiresTwoFactor)
        {
            // Handle 2FA flow if you have it
            return RedirectToAction(nameof(VerifyAuthenticator), new { returnUrl, model.Email });
        }
        if (result.IsLockedOut)
        {
            ModelState.AddModelError(string.Empty, "Account locked out. Please try again later.");
            return View(model);
        }
        else
        {
            ModelState.AddModelError(string.Empty, "Invalid login attempt.");
            return View(model);
        }
    }
    // If we got this far, something failed, redisplay form
    return View(model);
}

Why This Works (and Why It’s Great) #

• Separation of concerns: IdentityServer stays focused on authorization logic, while your Web app handles UX and user management. This makes updates, scaling, and debugging easier.
• Reusability: The same IdentityServer instance can serve multiple clients (other web apps, mobile apps, APIs) without duplicating login/registration logic.
• Flexibility: You can customize the user UI completely without touching the core auth service—no need to hack IdentityServer’s built-in UI.

This setup is fully supported by IdentityServer4’s modular design. Many enterprise teams use this exact pattern to keep their auth systems clean and scalable.

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