.Net5多MVC Web应用集中式身份认证：JWT与Cookie的选型及实现问题咨询

Great question—let’s break this down based on your specific scenario (three MVC apps with auth centralized in the User app) and address each of your concerns.

First: Go with Cookies (They’re Made for MVC) #

Since your Admin and Product apps are server-rendered MVC apps (not APIs), cookie-based authentication is the clear, low-friction choice here. Here’s why it fits your use case perfectly:

• .NET’s built-in Identity system integrates seamlessly with cookies for MVC. When a user logs in via the User app, you can configure a shared authentication cookie that works across all your apps (as long as they’re on the same domain/subdomain). The browser automatically sends this cookie with every request, so things like @Html.ActionLink or form posts will just work—no manual token passing required.
• You don’t need to switch to React or any frontend framework. Your existing MVC workflows (server-side rendering, Razor helpers) will continue to function as expected without extra client-side code.
• Handling common auth tasks (expiration, logout, refresh) is baked into .NET’s middleware, so you don’t have to reinvent the wheel.

To set up shared cookies between your apps:

• All apps must use the same authentication scheme (e.g., CookieAuthenticationDefaults.AuthenticationScheme).
• Configure data protection to share encryption keys across apps. In .NET 5, you can use a shared storage location (like a network file share or cloud key vault) so each app can decrypt the cookie’s contents.
• Set the cookie’s domain to a parent domain (e.g., .yourcompany.com) if your apps are on subdomains like user.yourcompany.com or admin.yourcompany.com.

When Would JWT Make Sense? (Probably Not for Your MVC Apps) #

JWT is designed for API-first scenarios—think SPAs, mobile apps, or service-to-service communication. For server-rendered MVC, using JWT adds unnecessary complexity:

• @Html.ActionLink doesn’t automatically include JWT tokens in requests. To pass the token, you’d either have to:
  • Store the JWT in a cookie (which is just using cookies to carry JWT—so why not use the built-in cookie auth directly?), or
  • Use JavaScript to intercept every request and add the JWT to the Authorization header (this would require moving parts of your frontend to React or vanilla JS, which defeats the purpose of using MVC).
• Transferring the JWT from the User app to other apps is tricky. You could redirect with the token in the query string (insecure—visible in URLs/logs), store it in local storage (risky for XSS attacks), or use a session (but sessions are per-app unless you share them, which adds more complexity).

If you absolutely need to use JWT with MVC (e.g., to support both MVC and API clients), a hybrid approach works:

• After login in the User app, generate the JWT and store it in an HttpOnly, Secure cookie.
• Your MVC apps can read this cookie, extract the JWT, and validate it using JWT middleware.
• For AJAX requests, you’d read the JWT from the cookie and attach it to the Authorization header as Bearer <token>.

Final Recommendation #

For your all-MVC platform, stick with shared cookie authentication. It’s the most natural fit for .NET MVC, requires minimal setup, and plays nicely with all the server-rendered features you’re already using. You won’t have to rewrite your frontend, and handling cross-app auth will be straightforward with shared data protection and cookie configuration.

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