From 7895985406646c16cb5224700a677bd3afaea046 Mon Sep 17 00:00:00 2001 From: RolandGuijt Date: Fri, 20 Dec 2024 10:41:50 +0100 Subject: [PATCH] Clarify boundness Co-authored-by: Joe DeCock --- IdentityServer/v7/docs/content/tokens/refresh.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/IdentityServer/v7/docs/content/tokens/refresh.md b/IdentityServer/v7/docs/content/tokens/refresh.md index 06ab9de2..2f952587 100644 --- a/IdentityServer/v7/docs/content/tokens/refresh.md +++ b/IdentityServer/v7/docs/content/tokens/refresh.md @@ -50,7 +50,11 @@ The [Duende.AccessTokenManagement](https://github.com/DuendeSoftware/Duende.Acce ## Binding refresh tokens Refresh tokens are a high-value target for attackers, because they typically have a much higher lifetime than access tokens. -It is recommended that a refresh token is either bound to the client via a client secret or using [Proof of Possession]({{< ref "pop" >}}). +However, refresh tokens for _confidential clients_ are bound to that client; they can only be used by the client they are issued to and the client is required to authenticate itself in order to do so. An attacker able to obtain a refresh token issued to a confidential client cannot use it without the client's credentials. + +Refresh tokens issued to public clients are not bound to the client in the same way since the client cannot authenticate itself. Instead, we recommend that such refresh tokens be sender-constrained using [Proof of Possession]({{< ref "pop" >}}). + +You can further reduce the attack surface of refresh tokens using the following techniques. #### Consent We encourage you to request consent when a client requests a refresh token, as it not only makes the user aware of the action being taken, but also provides them with an opportunity to opt-out if they choose.