Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

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

Revoking an OAuth grant removes the authorization relationship that lets an application obtain or use tokens, but revoking one token is not always the same operation. The authorization server decides which related access and refresh tokens become invalid and how quickly other servers learn about the change. Access-token and refresh-token lifetimes are also provider policies, not universal OAuth values. Use the provider’s connected-app controls for a user-initiated removal, or its HTTPS revocation endpoint for an application-initiated request, then handle invalid-token responses by stopping retries and sending the user through authorization again.

What is an OAuth grant, and how is it different from a token?

An OAuth grant is the authorization relationship established when a resource owner consents to a client using specified scopes against a resource server. Access tokens and refresh tokens are credentials issued within that relationship. RFC 7009 describes a token as “a string representing an authorization grant issued by the resource owner to the client.” In practice, the grant is the relationship and policy; tokens are the items presented to obtain or call resources.

That distinction matters when access is removed. A provider may invalidate one submitted token, every token associated with a grant, or both the grant and its tokens. OAuth does not require every provider to expose the same user interface or propagation behavior. Treat the provider’s documented semantics as authoritative rather than assuming that deleting a token, disconnecting an app, and signing out of every service are equivalent.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

How do I revoke an OAuth grant?

User-initiated removal in an account

Most providers place this control under names such as Authorized applications, Connected apps, or Applications. The general procedure is:

  1. Sign in to the account at the provider that issued the authorization.
  2. Open the provider’s authorized-app or connected-app settings.
  3. Find the application and inspect whether the entry represents a personal, organization, or administrator-managed authorization.
  4. Choose Revoke, Remove access, or the provider’s equivalent, and confirm.
  5. Record the time and test the application. It should fail to use credentials that the provider says were associated with the removed authorization.

Labels and scope vary. A personal-account control may not remove an organization approval, a separate application installation, unrelated API keys, or a local session stored by the application. For a suspected compromise, use the provider’s incident controls and review other credentials and active sessions separately.

Application-initiated revocation

RFC 7009 defines a revocation endpoint. The client sends an HTTPS POST containing the token and, optionally, a token_type_hint. The endpoint must be obtained from a trustworthy authorization-server configuration; do not substitute a URL copied from an unrelated provider.

POST https://authorization.example/revoke
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <client-credentials-if-required>

token=<token-value>&token_type_hint=refresh_token

The server validates any required client authentication and token ownership, then invalidates the token under its policy. Implementations MUST support refresh-token revocation and SHOULD support access-token revocation, as those words are used in the standard. A provider can therefore support one operation more completely than another.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

What does the revocation response mean?

A successful revocation response is HTTP 200. RFC 7009 deliberately specifies the same 200 response when the submitted token was already invalid or unknown, so a client cannot use the response to discover whether a token had previously been valid. This reduces information leakage and makes revocation idempotent from the client’s perspective.

An HTTP 503 response means the client should assume the token still exists and may retry after a reasonable delay. Implement bounded retries with backoff; do not turn a service outage into an endless stream of revocation requests. Other HTTP errors generally indicate a request, authentication, or endpoint problem that should be logged and diagnosed according to the provider’s documentation.

Does revoking a token immediately stop access?

At the authorization server, invalidation is intended to take effect immediately. Distributed deployments can nevertheless have a propagation delay. The more important question is what the resource server checks when it receives an access token.

Opaque or centrally checked access tokens

If a resource server consults the authorization server, an introspection service, or a shared revocation store for each request, it can learn about invalidation quickly. The actual delay depends on cache and replication policy. A provider’s documentation should state the effective behavior; OAuth itself does not supply a universal number of seconds.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Self-contained access tokens

A self-contained token, such as a signed token whose claims can be verified locally, may continue to validate at a resource server that has not consulted the authorization server since issuance. RFC 7009 identifies additional backend interaction or shorter access-token lifetimes as design approaches when a narrow revocation window is required. Revoking a refresh token therefore stops that credential from obtaining new access tokens, but an already issued access token can remain usable until its own expiry or until the resource server checks a revocation mechanism.

What happens to related tokens?

Action What the standard says What you must verify with the provider
Revoke an access token The server may also revoke its related refresh token. Whether the refresh token, grant, or sibling access tokens are invalidated.
Revoke a refresh token If access-token revocation is supported, the server should also invalidate access tokens based on that grant. Whether already issued access tokens are rejected immediately or only after expiry/propagation.
Revoke a grant in account settings The provider applies its account-level policy. Whether all tokens for the app, one credential, organization approvals, and app sessions are covered.

These are standards-level relationships, not a promise that every provider implements every cascade. Never tell a user that one revocation instantly signs them out of every service unless the provider explicitly documents that result.

Do access tokens expire, and how long do OAuth tokens last?

OAuth defines no universal lifetime in minutes, hours, or days. The authorization server sets access-token and refresh-token policy, often based on risk, scope, client type, and whether the token is used actively. An access token can expire while its refresh token remains usable, and a refresh token that expires or is revoked cannot continue supplying new access tokens. Those are separate validity decisions.

Refresh-token security recommendations

RFC 9700 (January 2025) recommends that refresh tokens expire after a period of client inactivity, with the period chosen by the authorization server and potentially adjusted for the sensitivity of the grant. The server should make a risk-based decision about issuing refresh tokens at all. When issued, a refresh token must be bound to the consented scope and resource servers.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

For public clients, RFC 9700 requires refresh-token rotation on use with replay detection, or a sender-constrained design. Rotation means the client receives a replacement token and the previous one becomes unusable; replay detection lets the server react when an old token is presented again. The same specification allows a server to revoke refresh tokens after events such as a password change or authorization-server logout.

Best Value
BookFactory Security Pass Down Log Book, Wire-O, 100 Pages
  • Made in USA - Proudly produced in Ohio by a Veteran-owned business
  • Comprehensive Coverage: This BookFactory log book includes essential fields such as post/shift, time of change, date, weather conditions, and a designated space for detailed notes. This ensures that all relevant information is captured and easily accessible.
  • Sturdy Cover: The trans-lux cover protects the log book from wear and tear, ensuring its longevity and maintaining the integrity of your recorded data.
  • Essential Security Tool: This log book is an indispensable tool for any organization that values security and accountability. It helps to prevent misunderstandings, improve communication, and ensure a smooth transition between shifts.
  • Wire-O with Trans-lux cover, 100 Pages, Dimensions 8.5" x 11" - (Security-Pass-Down) Reorder SKU: LOG-100-7CW-PP(Security-Pass-Down)

Provider example: GitHub App credentials

GitHub’s current credential documentation, checked in October 2026, states that GitHub App user access tokens expire after eight hours by default and GitHub App refresh tokens expire after six months. Those values describe GitHub App credential types, not OAuth-wide defaults. Other GitHub credential types and other providers can use different lifetimes.

Credential Documented lifetime Scope of the figure
GitHub App user access token Eight hours by default GitHub’s documented GitHub App user-token policy; current documentation checked October 2026.
GitHub App refresh token Six months GitHub’s documented GitHub App refresh-token policy; current documentation checked October 2026.
Other OAuth providers or credential types Not stated here The issuing server’s policy controls the lifetime.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

How do users remove an app’s access?

Use the provider’s account-level authorized-app control and select the relevant application. GitHub documents that revoking an OAuth app authorization in personal account settings revokes tokens associated with that app. GitHub separately documents GitHub App authorization and organization-level controls, so identify the app type and account context before promising what will be removed.

After the provider confirms revocation, remove cached credentials from the client, invalidate local sessions where appropriate, and ask the user to authorize again only if continued use is intended. Revocation of an OAuth authorization does not automatically delete the user’s account, erase data held by the application, revoke unrelated API keys, or clear every browser session.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

How should an application handle an unexpectedly revoked token?

  1. Stop using the failing access or refresh token. Do not repeatedly submit a refresh token that the server has rejected as invalid or unauthorized.
  2. Discard the affected credential from secure storage and mark the authorization as unavailable.
  3. If an access token failed, determine whether the refresh token is still valid and whether the provider requires a new access token.
  4. If the refresh token is invalid, expired, or revoked, send the user through the provider’s authorization flow again, preserving the originally requested scope only with fresh consent where required.
  5. Tell the user what happened without exposing token values. Include a recovery action, such as reconnecting the app or contacting an administrator when organization approval is involved.
  6. Record non-sensitive diagnostics: provider, token type, endpoint, timestamp, HTTP status, and correlation identifier. Never log the raw token.

Unexpected invalidation can result from a user revoking access, a password or security event, inactivity expiry, replay detection, administrator action, or provider policy. A successful refresh before a user request does not prove that a grant will remain valid for the next request.

How should you compare OAuth providers or credential options?

When more than one connected app or credential type is involved, compare the properties that determine actual user impact rather than comparing token strings alone:

Comparison question Why it matters
Does the control revoke one token, all app tokens, or the underlying grant? It determines whether other devices and sessions continue to work.
Are access tokens opaque or self-contained? This affects how quickly resource servers can learn that a token was revoked.
What are the access- and refresh-token lifetimes? Short access lifetimes limit exposure; refresh policy determines how long silent renewal can continue.
Are refresh tokens rotated, replay-detected, or sender-constrained? These controls limit damage if a refresh token is copied.
Do user, organization, and administrator controls differ? A personal revocation may not remove an organization authorization or installation.

Common mistakes and the correct interpretation

  • “HTTP 200 proves the token was active.” It does not; 200 also covers an invalid or already revoked token.
  • “Revoking a refresh token instantly kills every access token.” The server’s policy, token format, caches, and propagation determine that result.
  • “All OAuth access tokens last one hour.” No OAuth-wide lifetime exists; use the issuer’s documentation.
  • “Deleting the app’s local login revokes OAuth.” Clearing local state does not notify the authorization server.
  • “Revocation signs the user out everywhere.” It may not affect unrelated sessions, API keys, or credentials issued by another service.
  • “Keep refreshing until it works.” Repeated use of a revoked refresh token can worsen an incident and can trigger replay defenses.

Standards to consult

For the protocol operation, status behavior, and token relationships, read OAuth 2.0 Token Revocation (RFC 7009). For current security guidance on refresh-token issuance, rotation, sender constraint, replay detection, inactivity expiry, and risk-based policy, read OAuth 2.0 Security Best Current Practice (RFC 9700). Provider account controls and lifetimes remain provider-specific; consult the issuer’s current documentation for the exact app and credential type.

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.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.