ASP.NET Identity：自定义RefreshToken与内置AspNetUserToken的选择困惑

1. 是否在重复造轮子？ #

不算完全重复，但存在功能重叠。AspNetUserTokens是Identity内置的通用令牌存储表，用于存放邮箱验证、密码重置、第三方登录等各类用户令牌，结构固定为UserId、LoginProvider、Name、Value。

你自定义的RefreshTokens集合本质也是存储用户刷新令牌，但优势在于可灵活扩展字段（比如你用到的ExpiresAt，还能添加IsRevoked、CreatedIp等）。如果你的刷新令牌仅需存储字符串和关联用户，用默认表即可；但如果需要额外字段实现精细控制（如过期检查、令牌撤销），自定义集合是合理的，不属于重复造轮子。

2. 能否用UserManager的令牌方法替代自研？ #

可以，但有局限性：

• 这些方法通过LoginProvider和TokenName区分令牌类型（比如指定LoginProvider = "JwtRefreshToken"、TokenName = "RefreshToken"），默认将令牌字符串存在AspNetUserTokens的Value字段。
• 若刷新令牌仅需存储字符串，完全可以用SetAuthenticationTokenAsync存储、GetAuthenticationTokenAsync读取；但如果需要存储ExpiresAt这类额外信息，默认方法无法支持——要么把信息编码到令牌字符串中（比如用JWT格式的刷新令牌），要么只能继续用自定义集合。

从你的代码来看，你需要直接在数据库中检查刷新令牌的过期时间，这种场景下自定义集合更合适，默认方法无法直接满足需求。

3. 是否需要实现自定义TokenProvider？ #

取决于你的使用方式：

• 如果你只是用Set/GetAuthenticationTokenAsync存取值令牌字符串，自己负责生成（比如你的tokenService.GenerateRefreshToken()）和验证逻辑，不需要自定义TokenProvider，直接调用方法即可。
• 如果你想把刷新令牌的生成、验证、过期逻辑完全集成到Identity的令牌体系中，就需要实现自定义TokenProvider（继承IUserTwoFactorTokenProvider<TUser>），因为默认的DataProtectorTokenProvider等是针对验证类令牌设计的，不适合JWT刷新令牌场景。

方案建议 #

结合你当前的实现（需要存储ExpiresAt并在数据库中检查过期），继续使用自定义RefreshTokens集合是更合理的选择。默认的AspNetUserTokens表灵活性不足，无法满足你当前的业务需求，所以你的实现不算重复造轮子。

如果后续需要简化存储逻辑，且能接受把过期信息编码到刷新令牌中（比如用JWT作为刷新令牌，包含过期时间），可以考虑切换到Identity的默认令牌方法，此时不需要自定义集合，但需要自己解析JWT来验证过期。

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