Is your feature request related to a problem? Please describe the problem.
Decrease the risk of compromised refresh tokens being reused / decrease replay attacks.
I noticed that a refresh token issued by the .NET 8 Identity Endpoints can be used over and over and over to get new tokens. As long as it hasn't expired, a week+?
Describe the solution you'd like
As soon as a refresh token is used to get new tokens, the used refresh token should be invalidated / inactive so it can no longer be used to get new tokens.
It's usually done by storing the issued refresh token in a database table. In which its column e.g. IsUsed is updated to true whenever a refresh is requested. At refresh a lookup happens in that table for an existing refresh token, this is another way of knowing that the token was issued by 'us'. The IsUsed value is also checked, if true, don't continue / don't accept it.
Is it an idea to use that AspNetUserTokens table for that?
Additional context
By now I'm more aware of the inner workings and intentions of the .NET 8 Identity Endpoints. Regardless, this request is a small security improvement, not a request to support beyond simple scenario's. I understand it's not meant to become a full-fledged token server.
Ps, as a European I detest cookie banners so I try to avoid those at all costs. That's partly why I'm hoping these Identity Endpoints could become a go-to solution for SPA + API auth regardless of whether cookies are supported.
Laftek
commented
1 month ago
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
Decrease the risk of compromised refresh tokens being reused / decrease replay attacks.
I noticed that a refresh token issued by the .NET 8 Identity Endpoints can be used over and over and over to get new tokens. As long as it hasn't expired, a week+?
Describe the solution you'd like
As soon as a refresh token is used to get new tokens, the used refresh token should be invalidated / inactive so it can no longer be used to get new tokens.
It's usually done by storing the issued refresh token in a database table. In which its column e.g.
IsUsedis updated to true whenever a refresh is requested. At refresh a lookup happens in that table for an existing refresh token, this is another way of knowing that the token was issued by 'us'. TheIsUsedvalue is also checked, if true, don't continue / don't accept it.Is it an idea to use that
AspNetUserTokenstable for that?Additional context
By now I'm more aware of the inner workings and intentions of the .NET 8 Identity Endpoints. Regardless, this request is a small security improvement, not a request to support beyond simple scenario's. I understand it's not meant to become a full-fledged token server.
Interesting read: https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/#Refresh-Token-Rotation
Ps, as a European I detest cookie banners so I try to avoid those at all costs. That's partly why I'm hoping these Identity Endpoints could become a go-to solution for SPA + API auth regardless of whether cookies are supported.
If you need some inspiration: