What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
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
A password reset does not automatically invalidate every JWT already issued. If an API accepts a token based on its signature and claims alone, an unexpired access token may keep working until it expires. To reject it sooner, the system needs a revocation or current-session check that the relevant resource servers actually consult.
Why a password reset may not stop an existing JWT
A password is a credential used to authenticate a user. An access token is a separate credential that may already be held by a browser, app, or attacker. Changing the password changes the first; it does not rewrite tokens already issued.
JWTs can carry claims such as an issuer, audience, and expiration time. A resource server that verifies the signature and required claims can make its decision from the token itself, without checking the user’s current password or session. The JWT specification defines the token format, while OWASP recommends validating claims including issuer, audience, and expiry for API access control. Neither makes password reset an automatic revocation signal. RFC 7519; OWASP REST Security Cheat Sheet.
That is an architectural distinction, not a rule that all JWT-backed systems behave alike. If your application checks current session or revocation state during requests, it can reject a still-unexpired token. If its resource servers validate tokens offline and have no such check, they may not know that a password was reset or an account was compromised.
#1 Best Overall
Access tokens and refresh tokens are different
An access token is presented to a resource server to authorize a request. A refresh token is used with an authorization server to obtain new access tokens. Revoking a refresh token can stop future renewal, but that alone does not prove that every resource server has stopped accepting an access token it already issued.
RFC 9700, the IETF’s January 2025 OAuth 2.0 security best-current-practice document, says authorization servers may automatically revoke refresh tokens after a password change or logout. That can prevent those refresh tokens from obtaining new access tokens. The application still needs a separate policy for access tokens already issued and a way for each relevant resource server to enforce it. RFC 9700.
Ways to handle tokens after a password reset
Choose based on how quickly you need to reject an already-issued access token, whether resource servers can consult shared state, and what operational cost that adds. These approaches can be combined.
| Approach | Effect on an issued access token | What resource servers need | Trade-off |
|---|---|---|---|
| Short access-token lifetime | Limits acceptance to the token’s expiration; does not revoke it immediately. | Signature and claim validation, including expiry. | Reduces the exposure window without a per-request revocation lookup, but does not provide immediate rejection. |
Issuer-and-jti denylist |
Can reject a listed token before expiry. | Access to a current denylist when validating requests. | Adds state, lookup cost, and consistency and availability concerns across services. |
| OAuth revocation endpoint | Can revoke tokens according to the authorization server and resource-server implementation; propagation delay may occur. | Support for the revocation mechanism and a way for resource servers to learn the result. | Behavior depends on provider capability and deployment; an offline JWT verifier is not automatically updated. |
| Refresh-token revocation | Stops the revoked refresh token from renewing; treatment of already-issued access tokens is separate. | Authorization server must enforce refresh-token revocation; access-token enforcement still needs its own mechanism. | Useful for preventing renewal, but insufficient by itself for immediate access-token rejection. |
| Token Status List | Can provide token status for consumers that support the mechanism. | A supported status-list implementation and consumer retrieval of status. | Availability and behavior depend on the issuer and consumers’ actual support. |
Short-lived access tokens
Short expiration bounds how long a stolen bearer access token can remain valid if no earlier revocation check exists. It is a mitigation, not a password-reset hook: a token can still be accepted until it expires. OWASP identifies short token expiration as one way to mitigate token reuse. OWASP JSON Web Token Cheat Sheet.
Issuer-and-jti denylist
For early rejection, OWASP’s REST guidance describes recording a unique, server-issued jti (optionally combined with aud) when a session ends, then rejecting that token until its expiration. OWASP’s JWT guidance gives issuer and jti as a typical key pattern. As the REST guidance puts it: “When an explicit session termination event occurs, a unique, server-issued identifier (the jti claim, optionally combined with aud) should be submitted to a denylist on the API which will invalidate that JWT for any requests until the expiration of the token.” OWASP REST Security Cheat Sheet; OWASP JSON Web Token Cheat Sheet.
Every resource server that must reject the token needs a dependable way to consult the denylist. With multiple services, the design must account for how updates propagate and what happens if the state store is unavailable or stale. OWASP warns against using raw JWT bytes or a token hash as the denylist key because alternative valid representations can undermine that approach. Follow an issuer-and-jti pattern or assess another mechanism appropriate to the token profile.
OAuth revocation and refresh-token revocation
RFC 7009 defines an OAuth token-revocation endpoint using a POST request. It states: “Implementations MUST support the revocation of refresh tokens and SHOULD support the revocation of access tokens.” Revocation can take time to propagate. The RFC also says revoking a refresh token should invalidate associated access tokens only when the authorization server supports that capability. Check what the specific provider and resource servers implement rather than assuming the standard makes every offline JWT validator instantly aware. RFC 7009.
For password-change handling, an authorization server may revoke refresh tokens under RFC 9700. That prevents renewal through those tokens; access tokens already issued still need an explicit enforcement strategy. Logout has the same distinction: ending a login session and stopping all previously issued access tokens are not necessarily the same operation.
Best Value
Token Status Lists
OWASP describes Token Status Lists as an issuer-side option in which a token identifies a list and an index consumers can use to obtain its status. This is only useful when the issuer and consuming resource servers support the mechanism and its retrieval behavior; JWT libraries and identity providers should not be assumed to support it by default. OWASP JSON Web Token Cheat Sheet.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Reduce the impact of a stolen token
Sender-constrain access tokens
RFC 9700 recommends sender-constraining access tokens, for example with mutual TLS (mTLS) or Demonstrating Proof of Possession (DPoP). A caller must prove possession of key material associated with the token, which can prevent an attacker who has only copied the token from using it. It is not revocation, and it cannot guarantee protection if both the token and the associated key material are compromised. RFC 9700.
Restrict each token’s audience
RFC 9700 says access tokens should be limited to specific resource servers, and resource servers must reject tokens not intended for them. Audience restriction limits where a leaked token can be used; it does not stop use at the intended audience or end the token’s validity after a password reset. RFC 9700.
Quick Recap
What to verify in your implementation
- Identify each token type. Determine which credentials are access tokens and which are refresh tokens, and which service validates or consumes each.
- Trace the password-reset and logout flows. Confirm whether they revoke refresh tokens, record access-token revocations, or only change the password or session record.
- Check the resource-server decision path. Verify whether it checks only signature and claims or also consults current session, denylist, or status information.
- Test the distributed behavior. Establish how quickly each resource server learns about revocation and what it does when the status source is unavailable or behind.
- Choose a policy for stolen tokens. Set an access-token lifetime that bounds exposure, and add an online revocation or status mechanism if the required response time is shorter than that lifetime.
- Limit replay impact. Where appropriate, use sender constraints and audience restriction alongside—not instead of—the revocation policy.
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.
