.NET Core 3.0中AspNetUserToken与自定义JWT令牌的差异对比

I'm building a small side-hustle API and need to implement JWT authentication. In past projects, I always used a custom implementation for JWT generation and validation, but this time I want to speed up development using ASP.NET Identity and Entity Framework, leveraging existing tools.

While writing my GenerateToken method, I noticed that many tables created by Identity aren't being used, which led me to look into the AspNetUserTokens table. I'm wondering how my original custom code compares to using Identity's built-in token methods:

Custom Implementation:

private object GenerateToken(IdentityUser user) {
    var tokenHandler = new JwtSecurityTokenHandler();
    var key = Encoding.UTF8.GetBytes(ApiConfig.JwtSecretKey);
    var tokenDescriptor = new SecurityTokenDescriptor {
        Subject = new ClaimsIdentity(new Claim[] {
            new Claim(ClaimTypes.Name, user.UserName),
            new Claim(ClaimTypes.Email, user.Email),
        }),
        Expires = DateTime.UtcNow.AddSeconds(double.Parse(ApiConfig.JwtExp)), //TODO: Try parse
        SigningCredentials = new SigningCredentials(new SymmetricSecurityKey(key), SecurityAlgorithms.HmacSha256Signature),
        Audience = ApiConfig.JwtAudience,
        Issuer = ApiConfig.JwtIssuer
    };
    var token = tokenHandler.CreateToken(tokenDescriptor);
    return tokenHandler.WriteToken(token);
}

ASP.NET Identity Approach:

//Removes existing token
await _userManager.RemoveAuthenticationTokenAsync(user, "lboard", "login");
//Creates a new one
var newToken = await _userManager.GenerateUserTokenAsync(user, "lboard", "login");
//Set the new token for the user
await _userManager.SetAuthenticationTokenAsync(user, "lboard", "login", newToken);

What are the key differences between these two approaches? Is there an advantage to sticking with my custom implementation, or is using Identity's built-in methods the better choice?

Key Differences & Recommendations #

Let’s break down the core distinctions and help you pick the right approach for your side project:

1. Token Type & Validation Model #

• Custom JWT: This is a self-contained, stateless token. All critical data (claims, expiry, issuer/audience) is encoded directly into the token string. Validation only requires verifying the signature against your secret key—no database lookup is needed for every request.
• Identity’s Token Methods: The token generated here is a reference token by default. It gets stored in the AspNetUserTokens table, and validation requires checking the database to confirm the token exists, isn’t revoked, and belongs to the user. This lets you easily revoke tokens (like your RemoveAuthenticationTokenAsync call) but adds a database hit on each validation.

2. Control & Flexibility #

• Custom JWT: You have full control over every aspect of the token. Add any custom claims, tweak signing algorithms, set granular expiry rules, or adjust validation logic to fit external services that expect standard JWTs. It’s perfect if you need to integrate with OAuth2 providers or have unique token structure requirements.
• Identity’s Methods: These are tied tightly to Identity’s ecosystem. You’re working within its token provider system (your "lboard" provider here). While you can build custom token providers, you’re constrained by Identity’s framework. This limits low-level control but eliminates boilerplate for token storage and revocation.

3. Maintenance & Boilerplate #

• Custom JWT: You’re on the hook for all validation logic, secure secret key management, and any token revocation features (which would require building your own database table to track invalid tokens). It’s more upfront work but gives you full ownership of the system.
• Identity’s Methods: Identity handles most of the heavy lifting—token storage, revocation, and basic validation are built-in. If you’re already using Identity for user management (sign-ups, password resets), this integrates seamlessly without extra code for token tracking.

4. Ideal Use Cases #

• Go Custom if:
  • You want a lightweight, stateless authentication flow
  • You need to integrate with third-party services that accept standard JWTs
  • You prefer full control over token structure and validation
• Use Identity’s Methods if:
  • You need token revocation (e.g., letting users log out of all devices)
  • You’re already using Identity for other user management features
  • You want to minimize custom code and rely on Microsoft’s tested implementations

A middle ground option: Use Identity for user management (registration, password handling) but generate a custom JWT instead of GenerateUserTokenAsync. This lets you leverage Identity’s user system while retaining control over the JWT’s stateless nature and structure.

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