iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Refresh tokens let an OAuth client obtain new access tokens without asking the user to sign in again every time an access token expires. That can make sessions more convenient while keeping access tokens short-lived—but a refresh token is a powerful credential, not a security feature by itself. OAuth defines refresh tokens by what they do, not by requiring them to be JWTs.
What access tokens and refresh tokens do
An access token is presented to a resource server to access a protected resource. It may expire or become invalid, limiting how long a compromised access token can be useful. A refresh token is sent to the authorization server to request a new access token; it is not a substitute access token to present to the resource server.
For example, an application can use an access token for API requests and, when that token expires, send its refresh token to the authorization server. If the request is valid, the server issues a new access token. The user usually does not need to enter credentials for each renewal. This is the logic behind pairing the two: the access token is used frequently and can be relatively short-lived, while the refresh token supports continued access under tighter controls.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWhy this can make login both safer and more practical
Shorter-lived access tokens can reduce the period in which a stolen access token remains usable. Refresh tokens can preserve a smoother session by allowing renewal behind the scenes instead of prompting for another sign-in whenever an access token expires. The tradeoff is that the refresh token itself may be usable to mint new access tokens, so it becomes a high-value credential.
#1 Best Overall
RFC 9700, the IETF’s OAuth 2.0 Security Best Current Practice published in January 2025, warns that an attacker who steals and replays a refresh token may obtain access tokens and act on the user’s behalf. The usability benefit therefore depends on protecting the refresh token and managing its lifecycle—not merely on issuing one.
A refresh token is not necessarily a JWT
“Refresh token” describes a credential’s role: it is used to request new access tokens. It does not specify the token’s encoding. OAuth does not require refresh tokens to be JSON Web Tokens (JWTs); an implementation may choose a JWT format, but that is a deployment decision.
JWT-specific security guidance applies when a system chooses JWTs. RFC 8725 provides best practices for JWTs and recognizes that JWT use for OAuth access tokens and refresh tokens depends on the deployment. Do not assume that every refresh token can be decoded as a JWT, or that making it a JWT automatically makes it safer.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →How to protect refresh tokens against theft and replay
Because a stolen refresh token can be replayed to obtain access tokens, RFC 9700 requires refresh tokens issued to public clients to be either sender-constrained or protected with refresh-token rotation. Public clients include clients that cannot reliably keep a secret confidential. The two approaches reduce risk in different ways.
| Approach | How it helps | Implementation and recovery considerations |
|---|---|---|
| Refresh-token rotation | Each successful refresh issues a new refresh token and invalidates the previous one. Reuse of the invalidated token can reveal likely replay. | The authorization server must track the relationship between rotated tokens. If an old token is reused, the server cannot know whether the attacker or the legitimate client presented it, so it can revoke the active token and require the user to authorize again. |
| Sender-constraining | Token use is bound to a client instance or proof of possession, so possession of the token alone should not be enough. | Requires managing keys or other proof material. RFC 9700 cites DPoP and mutual TLS as mechanisms. Protection is weakened if an attacker obtains both the token and the associated key material. |
What rotation does when an old token reappears
With rotation, every successful refresh replaces the refresh token and invalidates its predecessor while retaining their relationship. If the predecessor appears again, the authorization server can treat this as a likely compromise. Since it cannot distinguish the legitimate client from an attacker using the same invalidated token, it may revoke the currently active refresh token as well. The legitimate user may then need to sign in or obtain a fresh authorization grant.
What sender-constraining changes
Sender-constraining requires the client to prove possession of a key or other bound credential when using the token. This means a copied refresh token alone is less useful to an attacker. The client and authorization server must still handle that proof material securely; exposing both the token and its key can defeat the added protection.
Set scope, expiry, and revocation rules
Issuing a refresh token is a risk decision for the authorization server. If it issues one, RFC 9700 says the token must be bound to the scopes and resource servers the user consented to. That limits what renewed access can cover; a refresh token should not silently broaden the original authorization.
Recommended Free Tools
- Expire inactive tokens: RFC 9700 says inactive refresh tokens should expire. The authorization server determines the inactivity period through its policy.
- Revoke after security events where appropriate: The server may revoke refresh tokens after events such as a password change or an authorization-server logout.
- Plan for suspected compromise: Rotation can identify likely replay, but containment may invalidate the legitimate user’s active token too. Provide a clear route to reauthenticate and restore the session.
Browser-based applications need a reauthentication path
For browser-based OAuth applications, RFC 10017 specifies that refresh tokens must either be rotated on each use or sender-constrained. The user experience should account for expiry and revocation: when a refresh token can no longer be used, the browser client may need to start authorization again. A design can reduce unnecessary prompts, but it should not promise an uninterrupted session under every security event.
Best Value
Choosing an approach in practice
Rotation offers replay detection through token-family tracking, with the possibility that a detected replay also signs out the legitimate user. Sender-constraining ties token use to proof material, adding key or proof management and relying on that material remaining protected. Neither approach removes the need to protect credentials, enforce authorization boundaries, and provide a recovery path.
A sound design therefore treats refresh tokens as sensitive credentials: use TLS in transit, keep them confidential, constrain their scope and resource access, apply suitable expiry and revocation rules, and implement rotation or sender-constraining for public clients. The right session behavior balances fewer routine sign-in prompts with a deliberate reauthentication flow when a credential expires or compromise is suspected.
