关于IdentityServer 4的工作机制、用户管理及架构适配咨询

Hey there! Let’s break down your IdentityServer4 questions one by one—this tool can feel like a maze with all its components, but we’ll untangle it together.

IdentityServer4 doesn’t come with a built-in registration UI out of the box, but integrating a registration flow is straightforward. The most common approach is to pair it with ASP.NET Identity:

• You’ll build a registration page (either as part of your IdentityServer4 project or a separate app, though keeping it with IdentityServer is simpler for auth flows).
• When a user submits their registration details (username, password, email, etc.), you’ll use ASP.NET Identity’s APIs to create and save the user to your database.
• Once registered, the user can then use those credentials to log in via IdentityServer4’s login UI (which you’ll also set up, or use the quickstart templates as a base).

If you’re using the recommended ASP.NET Identity integration:

• Passwords are securely stored (hashed, not plaintext) by ASP.NET Identity, using its built-in password hashing mechanisms.
• Usernames and other user data are stored in a database of your choice (SQL Server, MySQL, PostgreSQL, etc.) via Entity Framework Core, which ASP.NET Identity uses by default.
• You can also implement custom user stores if you need to use a non-standard data source, but ASP.NET Identity’s default setup works for most use cases.

Absolutely—this is a very common and robust setup! Here’s how the flow works:

1. Your React app redirects users to IdentityServer4’s login/registration page when they need authenticated access.
2. After successful login, IdentityServer4 issues a JWT access token (and refresh token, if configured) to the React app.
3. The React app includes this JWT in the Authorization header when making requests to your ASP.NET Web API.
4. Your Web API is configured to validate the token against IdentityServer4, ensuring the user is authenticated and has the right permissions to access the API endpoints.

A quick note: ASP.NET Core 2 is a bit outdated, but IdentityServer4 does support it. If possible, upgrading to a newer LTS version (like 3.1 or 6.0) would give you better security patches and feature support, but your original plan is still workable.

In-memory users are purely for testing and rapid prototyping. Here’s the lowdown:

• They’re hardcoded directly in your IdentityServer4 setup (like in a list of user objects), and exist only in the server’s memory while it’s running.
• They’re great for spinning up a demo quickly without needing to set up a database, but they’re completely unsuitable for production:
  • Restarting the server wipes all in-memory users.
  • You can’t support user registration, profile updates, or password resets.
  • There’s no way to scale across multiple server instances (since each instance has its own separate memory).

For production, you’ll always want to use a persistent user store like ASP.NET Identity with a database.

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