Summary

Zendesk OAuth currently contains a failure scenario that can permanently break an otherwise healthy integration after a single transient infrastructure failure.

The issue is not related to OAuth itself, but to the way refresh token rotation is currently implemented.

If an application successfully receives a new access token and refresh token pair but cannot persist the new refresh token before an unexpected failure (application crash, database outage, network failure, process termination, etc.), there is no supported way to recover.

The integration permanently loses the ability to obtain new access tokens, even though the OAuth authorization itself remains valid.

For unattended integrations, this creates a single point of failure that application developers cannot eliminate on their own.

Why this matters now

The published API Token deprecation timeline makes OAuth the only authentication mechanism for the Ticketing, Help Center, and Voice APIs.

Once API Tokens are fully retired, this failure scenario becomes relevant to every unattended OAuth integration with no remaining authentication fallback.

Failure scenario

The sequence is straightforward:

1. The application stores a valid access token and refresh token.

2. The access token expires.

3. The application requests a new token pair.

4. Zendesk issues a new access token and a new refresh token while immediately invalidating the previous refresh token.

5. Before the application successfully persists the new refresh token, an unexpected infrastructure failure occurs.

6. The application restarts.

7. The only stored refresh token has already been invalidated.

8. The new refresh token has been lost.

9. Token refresh is no longer possible.

10. The customer must manually authorize the application again.

This is an irreversible failure caused by a temporary infrastructure issue.

Although the probability of this happening during any individual refresh operation is low, the probability approaches certainty over time for systems managing large numbers of OAuth installations.

Current behavior

Zendesk Support confirmed that this behavior is expected:

• the previous refresh token becomes invalid immediately;

• there is no grace period;

• there is no idempotent refresh operation;

• there is no token family or recovery mechanism;

• manual customer re-authorization is the only supported recovery path.

Support also confirmed that this represents a real gap in the current implementation that cannot be solved by application developers.

The core issue

The problem is not that refresh token rotation exists.

The problem is that a brief infrastructure failure occurring during a very small time window can permanently invalidate an integration, with no possibility of recovery.

This makes the reliability of the integration depend on the successful completion of a single persistence operation.

In distributed systems, crashes, database outages, process termination, and network interruptions are expected events. A robust authentication system should tolerate these failures without requiring end users to manually restore authorization.

Possible approaches

The exact implementation is less important than eliminating the irreversible failure scenario.

Possible approaches could include:

• allowing the previous refresh token to remain valid for a short grace period;

• making refresh operations idempotent;

• introducing refresh token family tracking;

• allowing recovery of the latest refresh token within a limited time window;

• or any other server-side mechanism that prevents permanent authorization loss after a transient persistence failure.

Request

I would like the product team to consider whether this architectural reliability gap could be addressed in a future release.

As Zendesk transitions to OAuth-only authentication, improving the resilience of refresh token rotation would significantly increase the reliability of unattended production integrations without reducing the security benefits of refresh token rotation.