Update refresh.md #546
Update refresh.md #546
Conversation
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://happy-ocean-048b8e60f-546.eastus2.azurestaticapps.net |
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://happy-ocean-048b8e60f-546.eastus2.azurestaticapps.net |
| The security of refresh tokens used by *public clients* can be improved by rotating the tokens on every use, because there is a chance that a stolen token will be unusable by the attacker. If a token is exfiltrated from some storage mechanism, a network trace, or log file, but the owner of the token uses it before the attacker, then the attack fails. However, this comes at the cost of reliability and database pressure and is only necessary for public clients (see [below](#avoid-rotation)). Rotation is configured with the *RefreshTokenUsage* client setting and, beginning in IdentityServer v7.0, is disabled by default. | ||
|
|
||
| When *RefreshTokenUsage* is configured for *OneTime* usage, rotation is enabled and refresh tokens can only be used once. When refresh tokens are used with *OneTime* usage configured, a new refresh token is included in the response along with the new access token. Each time the client application uses the refresh token, it must use the most recent refresh token. This chain of tokens will each appear as distinct token values to the client, but will have identical creation and expiration timestamps in the datastore. | ||
| Rotating the tokens on every use [has no security benefits](https://blog.duendesoftware.com/posts/20240405_refresh_token_reuse/) regardless of which type of client is used. And it comes with the cost of database pressure and reliability issues: Reusable refresh tokens are robust to network failures in a way that one time use tokens are not. If a one-time use refresh token is used to produce a new token, but the response containing the new refresh token is lost due to a network issue, the client application has no way to recover without the user logging in again. Reusable refresh tokens do not have this problem. |
There was a problem hiding this comment.
"no security benefits" is a bit too strong of a statement. A persistent attacker (persistent in the sense that the attack persists/is on-going) can defeat rotation, but there are other attacks that would be stopped by rotation. I would say something like "limited security benefits"
There was a problem hiding this comment.
Also, we should start this section by explaining what Rotation is so that the reader has more context. I think some of the cut paragraphs above should come back.
There was a problem hiding this comment.
@josephdecock Agreed. The part about how to config now goes first, the part about the motivation around using ReUse second and I've rewritten some sentences to make it glue together.
Our stylesheet makes ## and ### indistinguishable
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://happy-ocean-048b8e60f-546.eastus2.azurestaticapps.net |
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://happy-ocean-048b8e60f-546.eastus2.azurestaticapps.net |
Co-authored-by: Joe DeCock <[email protected]>
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://happy-ocean-048b8e60f-546.eastus2.azurestaticapps.net |
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://happy-ocean-048b8e60f-546.eastus2.azurestaticapps.net |
Updated text around reusable refresh tokens.
Discussion point:
In the sections below the part I've changed there are two sections "Accepting Consumed Tokens" and "Replay detection" that elaborate about the use of rotating tokens. Should that be shortened/adjusted?