An app can look disconnected while a credential issued earlier still works. OAuth refresh token revocation tells the authorization server to invalidate a token; whether existing access tokens stop working immediately depends on the server’s capabilities and policy. A useful disconnect flow therefore needs to explain both what it removes and what access may remain.
Two credentials with different jobs
An access token lets a client request a protected resource. A refresh token allows the client to obtain access tokens without asking the user to repeat the original authorization each time. Removing an app from a screen and invalidating its credentials are different operations that a product needs to coordinate.
RFC 7009, the IETF’s OAuth token-revocation specification, provides a mechanism for a client to tell an authorization server that a token is no longer needed. It explicitly discusses logout, identity changes and uninstalling an application as occasions for doing that cleanup.
This is a protocol mechanism, not a promise about every application’s logout button. To judge a particular service, read its documentation for disconnecting integrations, ending sessions and revoking credentials. A locally closed session may have a different scope from an authorization grant held at another service.
Refresh token vs access token
RFC 6749, the OAuth 2.0 framework, draws the line by audience. An access token is presented to the resource server, the API that holds the data. A refresh token is a credential “used to obtain access tokens,” and refresh tokens “are intended for use only with authorization servers and are never sent to resource servers.” The string is usually opaque to the client, so whether it is a JWT or a random value is the server’s choice, not something the client should rely on.
Issuing a refresh token is optional for the authorization server. Section 10.4 of the same RFC says refresh tokens must be kept confidential in transit and storage, shared only between the authorization server and the client they were issued to, and sent only over TLS.
| Access token | Refresh token | |
|---|---|---|
| Sent to | Resource server (the API) | Authorization server only |
| Used for | Requesting protected data | Getting new access tokens |
| Lifetime | Set by the server; RFC 6749 notes it may be shorter than the grant | Set by server policy; RFC 9700 says it should end after inactivity |
| Required? | Yes, for API calls | Optional for the server to issue |
Do refresh tokens expire, and what is rotation?
They can. RFC 9700, the IETF’s OAuth 2.0 security best current practice published in January 2025, says refresh tokens should expire if the client has been inactive for some time, with the period “at the discretion of the authorization server.” It also allows automatic revocation on security events such as a password change or logout at the authorization server.
Google’s documentation gives one provider’s concrete list. A refresh token might stop working when the user revokes access, when it has not been used for six months, or after a password change if it carries Gmail scopes, among other reasons. Google says apps should be written to expect that.
For public clients, such as mobile and single-page apps, RFC 9700 requires the server to detect refresh-token replay in one of two ways. Sender-constrained tokens are cryptographically bound to one client instance. Refresh token rotation issues a new refresh token with every refresh and invalidates the previous one; if an old token is presented again, the server cannot tell whether the attacker or the legitimate client sent it, so it revokes the active token, and the user must authorize again.
What a revocation request does
The client sends an HTTP POST request to the authorization server’s revocation endpoint. RFC 7009 requires an HTTPS endpoint and says its location must come from a trustworthy source. The request includes the token; an optional token-type hint can identify it as an access or refresh token.
A confidential client also authenticates. The server checks that the token belongs to the requesting client before invalidating it. This ownership check matters: a revocation endpoint should not become an unrestricted mechanism for one client to manipulate another client’s credentials.
Implementations must support refresh-token revocation under this specification. Access-token revocation is recommended, but it is not the same mandatory capability. That distinction changes what a product can truthfully say after a user disconnects an integration.
| Operation | Question the product needs to answer |
|---|---|
| Close the app’s local session | Can another device or background process still act? |
| Revoke a refresh token | Can this client obtain new access tokens with it? |
| Revoke related access tokens | Are previously issued credentials also invalidated? |
| End the authorization grant | Which related tokens and permissions does server policy remove? |
These are review questions derived from the standard, not a claim that every provider exposes four separate controls.
Refresh-token revocation may leave a short window
RFC 7009 describes invalidation as immediate, while acknowledging practical propagation delays between servers. It also says that, when the server supports access-token revocation, revoking a refresh token should invalidate access tokens based on the same authorization grant.
A service that does not support access-token revocation has another boundary: already-issued access tokens are not immediately invalidated when the related refresh token is revoked. The standard tells deployments to account for that in their security analysis.
Consider a hypothetical integration whose access token has fifteen minutes left before expiry. If the server revokes only the refresh token, the client loses that route to obtaining new tokens. The existing access token may remain usable for its remaining lifetime. Fifteen minutes is an illustration, not a recommended setting or a measured provider behavior.
A product’s message should match its implementation. “Disconnected” can describe a completed local action, but a stronger statement about all access ending requires evidence about issued access tokens and the authorization grant.
A successful response does not prove the token existed
The revocation endpoint returns HTTP 200 both when it successfully revokes a token and when the client submits an invalid token. RFC 7009 gives both cases the same response because the desired condition, an unusable token, already holds for an invalid token.
That makes the endpoint’s response useful for finishing the client flow, but unsuitable as proof that a particular credential was active immediately beforehand. An audit record should distinguish the request’s outcome from any separate evidence about prior use.
The server can also return an unsupported-token-type error. An access token sent to a server that does not support revoking that type does not become invalid just because the client attempted the request.
Treat an unavailable endpoint as an unfinished action
If the server returns HTTP 503, RFC 7009 says the client must assume the token still exists. It may retry after a reasonable delay, with any Retry-After header indicating the expected unavailability period.
For a product team, this suggests a visible distinction between a confirmed revocation response and a cleanup operation waiting to be retried. A misleading success message hides the part of the operation that determines whether credentials remain usable.
Keep tokens out of ordinary diagnostic messages and screenshots. The endpoint handles security credentials, and the standard warns about counterfeit revocation endpoints capturing them. The same care that protects authorization needs to apply when authorization is removed.
Review the whole disconnect flow
Trace one integration from the user’s click to its server response. Record which credential is submitted, how the endpoint is discovered, how failures are handled and what the provider says about related tokens. Then check that the user-facing explanation describes that scope.
This review is an implementation checklist, not a report of a tested provider. It sits beside the questions in our passkey recovery analysis: removing a local object and changing server-side access both require precise descriptions. For delivery verification, see webhook signatures and replay protection.
Reporting & Sources
Protocol document inspected October 9, 2026: IETF RFC 7009, OAuth 2.0 Token Revocation, published August 2013. Added October 10, 2026: RFC 6749, The OAuth 2.0 Authorization Framework (October 2012), sections 1.5 and 10.4; RFC 9700, Best Current Practice for OAuth 2.0 Security (January 2025), section 4.14.2; Google Identity: refresh token expiration. This evergreen analysis explains the specification; it does not announce a new standard, claim a hands-on test, or state that all providers implement identical revocation behavior.
