Recommended Free Tools
A refresh token lets an OAuth client request a new access token when its current one expires, so people can stay signed in without repeatedly entering their credentials. That can make a login system more practical while keeping access tokens short-lived—but a refresh token is a high-value credential, not a safety feature by itself. OAuth defines refresh tokens by their purpose; it does not require them to be JWTs.
What access tokens and refresh tokens do
An access token is presented to a resource server, such as an API, to authorize a request. A refresh token is presented to the authorization server to request a replacement access token. It is not a substitute for the access token and generally is not the credential an API should accept for ordinary resource access.
As an Amazon Associate I earn from qualifying purchases.
The distinction addresses two different needs: access tokens are used frequently and can be kept short-lived, while a refresh token can support getting a new access token without asking the user to sign in again every time the first one expires. OAuth’s refresh-token role and protections are described in the OAuth 2.0 Security Best Current Practice (RFC 9700).
Why refresh tokens can improve the login experience
Shorter-lived access tokens limit how long a stolen access token may remain useful. Without a refresh mechanism, expiration can force the user to repeat the sign-in or authorization flow. With a refresh token, the client can ask the authorization server for a new access token, subject to the server’s policy and the token still being valid.
#1 Best Overall
This is a trade-off, not a free security gain: the refresh token may live longer and can be used to mint access tokens. An attacker who steals and replays it may act on the user’s behalf. The refresh token therefore needs stronger protection than a routine API value, and the system needs a clear path to reauthorization when renewal is no longer allowed.
A refresh token is not necessarily a JWT
“Refresh token” names the credential’s function, not its encoding. OAuth does not require refresh tokens to be JSON Web Tokens (JWTs); an implementation may choose another format. JWT security guidance applies when an implementation actually uses JWTs, and the JWT Best Current Practices (RFC 8725) treats OAuth access-token and refresh-token JWT use as deployment-specific.
So the title phrase “JWT refresh token” should be read as one possible design. Choosing JWT format does not itself make refresh-token use safer; security depends on how the credential is issued, stored, bound, validated, rotated or revoked.
Protecting a stolen refresh token
Because a refresh token can obtain new access tokens, an authorization server should issue one only when the risk and client design justify it. The client must keep it confidential and use TLS for communication with the authorization server. Where possible, binding token use to the client or a proof of possession makes a copied token harder to replay from another device or process.
For public clients—clients that cannot reliably keep a secret, such as many browser and native applications—RFC 9700 requires refresh tokens to be either sender-constrained or rotated. The two approaches contain different risks and have different operational costs:
| Protection | How it works | Operational implications |
|---|---|---|
| Refresh-token rotation | Each successful refresh issues a new refresh token and invalidates the token just used. The authorization server tracks the relationship between successive tokens so reuse of an invalidated token can be detected. | Requires server-side token-family tracking. Reuse suggests replay, but the server cannot know whether the attacker or legitimate client presented the old token; it can revoke the active token, requiring the user to authorize again. |
| Sender-constraining | Token use is tied to a particular client instance or proof of possession. RFC 9700 cites mechanisms such as DPoP and mutual TLS. | Requires managing the key or proof material. The protection is weakened if an attacker obtains both the refresh token and the material needed to prove possession. |
Neither method removes the need for sound credential storage, transport security and recovery planning. Rotation makes replay visible through reuse of a retired token; sender-constraining makes a stolen token less useful without its associated proof.
What happens during refresh-token rotation
- The client sends its current refresh token to the authorization server over TLS.
- If the request is accepted, the server returns a new access token and a replacement refresh token, and invalidates the old refresh token.
- The client replaces its stored refresh token with the new one. It should not continue using the invalidated value.
- If the old token appears again, the server treats that reuse as a likely compromise signal. It may revoke the active token in the same token family; the legitimate client may then need to obtain a new authorization grant.
That final step is an intentional containment trade-off: the server cannot reliably distinguish the attacker from the legitimate client when both present credentials from the same token history. A client that fails to save the replacement token can also lose the ability to refresh and may need to sign in again.
Scope, expiration and revocation rules
RFC 9700 says an issued refresh token must be bound to the scope and resource servers the user consented to. A refresh request must not quietly expand that authorization. The standard also says inactive refresh tokens should expire; the authorization server sets the inactivity period according to its policy, rather than following a universal duration.
Best Value
An authorization server may also revoke refresh tokens after security or account events, including a password change or logout at the authorization server. These lifecycle rules matter because a long-lived credential should not remain usable indefinitely just because it has not yet reached a fixed expiration date.
Browser-based applications and reauthentication
For browser-based OAuth applications, RFC 10017 specifies that refresh tokens must be rotated on each use or sender-constrained. It also notes that an expired refresh token can require the browser client to initiate authorization again.
Plan for that interruption explicitly: when refresh is denied or the token expires, the application should return the user to the authorization flow rather than promise a session that can never end. Rotation-related reuse can likewise force a fresh authorization grant, even for a legitimate user.
Free tools Windows power users keep installed
One-click scans. No signup required.
Quick Recap
Choosing a practical design
- Use access tokens with a lifetime appropriate to the API and the consequences of exposure; use refresh tokens only when avoiding repeated authorization prompts is worth the additional credential risk.
- For public clients, implement rotation or sender-constraining as RFC 9700 requires. Choose rotation when token-family state and reauthorization after suspected reuse are manageable; choose sender-constraining when the client can reliably handle proof-of-possession keys.
- Bind issued refresh tokens to the user’s approved scope and resource servers, define inactivity expiration, and decide which account or security events trigger revocation.
- Protect refresh tokens in the client, use TLS, and treat renewal failure as a normal route to reauthentication—not as a reason to weaken validation or keep accepting an expired credential.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
