Summary

  • draft-ietf-oauth-deferred-token-response-00 lets an OAuth authorization server defer a token request and return a sender-constrained deferral_code; that code represents one pending request and grants no resource access.
  • Cancellation uses the RFC 7009 revocation endpoint, which returns HTTP 200 both when it cancels the pending request and when it changes nothing. Support discovery and a confirming poll are therefore distinct evidence.
  • A delivered access token remains an independent credential. Cancelling the deferral code cannot be treated as token revocation or as proof that a resource operation stopped.

The reassuring answer that says almost nothing

OAuth token revocation deliberately avoids telling a caller whether a supplied token was valid. That weakens the endpoint as an oracle, but also means automation cannot promote 200 OK into “cancelled” without another observation.

The OAuth working-group Deferred Token Response revision 00 applies that boundary to token decisions that outlive the original request: human review, fraud analysis or external verification. If the client opts in and the server defers, the token endpoint returns HTTP 400 with authorization_pending, an opaque deferral_code, an expiry and a polling interval.

That first response is not a failed token hidden behind a new name. It is not a token response at all. It issues no access token and gives no access to a protected resource. The code is a sender-constrained credential for retrieving the eventual answer to one pending authorization request at the same server.

The draft is work in progress, not an RFC or deployment evidence. Its state machine shows how easily a familiar status code can be asked to certify a transition it was designed not to reveal.

One field name, two different clocks

The deferred response's expires_in belongs to the deferral code; after it elapses, polling returns expired_token. A successful poll has another expires_in for the access token. Reusing the first timer to refresh the second credential would collapse two lifetimes into one field name.

The polling interval appears only in the initial response. The client must retain it and add at least five seconds after slow_down. A dashboard that stores only the latest reply cannot reconstruct whether the client obeyed the cadence.

If the original request used DPoP or mutual TLS, the code is bound to the same key or certificate. A different execution context holding the string does not hold the same credential; the receipt needs a binding reference, not merely a code hash.

The callback does not deliver the answer

DTR may notify a registered HTTPS callback when a request resolves. The callback contains the deferral code and can be authenticated with a per-request notification token. It conveys neither the access token nor the outcome. Success, error and cancellation all produce the same basic instruction: poll now for the final response.

The callback can wake a worker, but cannot mark approval, token issuance or cancellation. Without a notification token it remains advisory until polling; even authenticated, it proves the sender rather than the final answer.

The draft recommends interval-respecting polling even with callbacks. Polling survives a lost or delayed message; the callback reduces latency. Two paths help only if neither impersonates the result.

Cancellation inherits deliberate ambiguity

To cancel, the client posts the exact deferral code to the authorization server's revocation endpoint and should supply the registered deferral-code token-type hint. If the code is recognized and belongs to that client, the server must atomically move the pending request to cancelled. It must suppress a callback whose delivery has not begun and make later polling return access_denied.

If the code is unknown, belongs to another client, or was redeemed, cancelled or expired, the endpoint still returns HTTP 200 and changes nothing. RFC 7009 prevents invalid tokens from producing a revealing error.

Revision 00 therefore defines revocation_endpoint_token_type_values_supported. A supporting server lists the deferral-code type; one that does not still returns 200. The draft warns that this is indistinguishable from successful cancellation.

The ordered receipt is support metadata, cancellation request and transport result, then a poll observing access_denied. The 200 belongs in the middle, not at the end.

The race has three possible credential states

If review completed successfully but no token was delivered, cancellation makes the code redeemed and then cancelled. A later poll returns access_denied; no token is issued.

If the successful token response has already reached the client, cancelling the deferral code must not revoke that access token. They are independent credentials with independent lifetimes. The client must revoke the access token explicitly if that is the intended outcome.

A callback may already be in flight; only delivery not yet begun must be suppressed. A late callback is compatible with valid cancellation and must not reopen the workflow.

The labels must be: pending, resolved but not delivered, and token delivered. “Cancelled” without that boundary is incomplete.

Consent can expire while the code remains alive

During a deferral lasting hours or days, consent can be withdrawn, a client disabled or a session ended. The server must re-evaluate those conditions before issuance; positive external review cannot override stale authorization.

The reviewer controls its decision, the authorization server issuance, the resource server admission, and the target operation its outcome. Authority does not transfer between them.

A token receipt is not an operation receipt. Scope, resource policy or business rules may still reject the action; the draft measures none of those outcomes.

A cancellation receipt should preserve the disagreement

A local receipt should record issuer and support-metadata digest; client and binding reference; a one-way code correlation rather than the secret; response time, expiry and poll interval; cancellation and retry lineage; confirming poll; callback status; and whether token delivery occurred.

After token delivery, add its separate revocation receipt; for action risk, add resource admission and controlled outcome. Do not put the secret code in general logs: the draft calls for refresh-token-like care and redaction.

This is a Minimum Initial Specification for evidence, not a global cancellation registry. Products can keep local storage and remediation while emitting a comparable bounded record.

In Lu Heng's Reality Layers, HTTP 200 is symbolic response, cancellation is state transition, access_denied is protocol observation, token revocation is another credential event, and the resource operation is executable outcome. Evidence strengthens by moving downward, not by copying the first message.

Sources

  1. Deferred Token Response revision 00
  2. DTR revision history
  3. DTR revision 00 HTML
  4. DTR revision 00 text
  5. RFC 6749 — The OAuth 2.0 Authorization Framework
  6. RFC 7009 — OAuth 2.0 Token Revocation
  7. RFC 8628 — OAuth 2.0 Device Authorization Grant
  8. RFC 8693 — OAuth 2.0 Token Exchange
  9. RFC 8705 — OAuth 2.0 Mutual TLS
  10. RFC 9449 — OAuth 2.0 DPoP
  11. RFC 9700 — OAuth 2.0 Security Best Current Practice
  12. IANA OAuth Parameters
  13. Lu Heng — Minimum Initial Specification
  14. Lu Heng — On Reality Layers
  15. Lu Heng — Running Code Primary