Delegated Refresh Tokens for OAuth 2.0 Token Exchange
draft-zhu-oauth-async-delegation-05
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Larry Zhu , Zate Berg | ||
| Last updated | 2026-08-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhu-oauth-async-delegation-05
OAuth Working Group L. Zhu
Internet-Draft Z. Berg
Intended status: Standards Track Atlassian
Expires: 4 February 2027 3 August 2026
Delegated Refresh Tokens for OAuth 2.0 Token Exchange
draft-zhu-oauth-async-delegation-05
Abstract
OAuth 2.0 Token Exchange permits an authorization server to issue a
refresh token when a client needs continued access after the original
credential is no longer valid. However, RFC 8693 does not define how
a refresh token issued by a delegated Token Exchange preserves the
subject, actor chain, resource restrictions, or other delegated
authorization state.
This specification profiles refresh tokens issued by delegated OAuth
2.0 Token Exchange for asynchronous and long-running workflows. It
defines authorization-server metadata advertising profile support and
a Token Exchange request signal by which a client requests delegated
continuation, together with preservation of subject and actor
relationships, client and actor binding, resource confinement, scope
monotonicity, authorization re-evaluation, rotation, task-scoped
revocation, and a bounded delegation lifetime. The common discovery
signal, request signal, and semantics enable autonomous agents and
other product components to interoperate with independently
implemented authorization servers across trust domains.
Because a client generally cannot determine the effective lifetime of
an opaque refresh token, this profile requires the client to request
continuation only for an identified asynchronous task and to promptly
revoke the refresh-token family when that task reaches a terminal
state. These requirements reduce unnecessary issuance and limit the
period in which residual delegated authority can be abused. The
profile uses the existing OAuth refresh token response and grant and
introduces no new token type or grant type.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Zhu & Berg Expires 4 February 2027 [Page 1]
Internet-Draft Delegated Refresh Tokens August 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Profile Overview . . . . . . . . . . . . . . . . . . . . . . 6
4. Issuance During Token Exchange . . . . . . . . . . . . . . . 6
4.1. Authorization Server Metadata . . . . . . . . . . . . . . 6
4.2. Requesting Delegated Continuation . . . . . . . . . . . . 7
4.3. Establishing Delegated Authorization State . . . . . . . 8
4.4. Issuing the Refresh Token . . . . . . . . . . . . . . . . 9
4.5. Token Representation . . . . . . . . . . . . . . . . . . 10
5. Using a Delegated Refresh Token . . . . . . . . . . . . . . . 10
5.1. Refresh Request . . . . . . . . . . . . . . . . . . . . . 10
5.2. Client and Actor Binding . . . . . . . . . . . . . . . . 11
5.3. Authorization Re-evaluation . . . . . . . . . . . . . . . 11
5.4. Successful Response . . . . . . . . . . . . . . . . . . . 12
5.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 12
6. Rotation and Bounded Lifetime . . . . . . . . . . . . . . . . 13
7. Multi-Hop Example . . . . . . . . . . . . . . . . . . . . . . 14
8. Authorization Server Policy . . . . . . . . . . . . . . . . . 18
9. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. Relationship to Existing Specifications . . . . . . . . . . . 19
10.1. OAuth 2.0 Refresh Tokens . . . . . . . . . . . . . . . . 19
10.2. OAuth 2.0 Token Exchange . . . . . . . . . . . . . . . . 19
Zhu & Berg Expires 4 February 2027 [Page 2]
Internet-Draft Delegated Refresh Tokens August 2026
10.3. Continuation Request Signal . . . . . . . . . . . . . . 19
10.4. Authorization Server Metadata . . . . . . . . . . . . . 20
10.5. Resource Indicators . . . . . . . . . . . . . . . . . . 20
10.6. OAuth Security Best Current Practice . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
14. Normative References . . . . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
OAuth 2.0 Token Exchange [RFC8693] enables a client to exchange a
security token for a token suitable for a target service. In a
delegated exchange, the issued token represents a subject together
with an actor, using the semantics defined by RFC 8693. This pattern
is commonly used for on-behalf-of service calls in which each service
obtains an audience-specific access token for the next service.
A synchronous chain can rely on the incoming subject token while the
call is active. An asynchronous or long-running workflow cannot
always do so. A background job, scheduled task, workflow engine,
agent task queue, or multi-stage orchestration may need to obtain
another downstream access token after the original subject token has
expired or is no longer available.
Autonomous agents make this interoperability requirement especially
relevant. Such agents are commonly components of products rather
than isolated deployments, and those products need to work with
services in different trust domains and with different authorization-
server implementations. A product-specific convention understood by
only one authorization server does not let an agent reliably request
continuation elsewhere. Common authorization-server metadata, a
common request signal, and common continuation semantics allow an
agent to determine whether an authorization server supports delegated
asynchronous continuation and to use that capability consistently.
This specification does not make a refresh token portable between
authorization servers; each refresh token remains bound to, and
usable only at, its issuing authorization server.
Section 2.2.1 of [RFC8693] already permits a successful Token
Exchange response to contain a "refresh_token", including for user-
not-present and offline scenarios. Section 6 of [RFC6749] defines
how that refresh token is used, and [RFC8707] enables a refresh
request to identify a target resource. This document does not create
another continuation credential. Instead, it profiles the existing
refresh token for delegated Token Exchange.
Zhu & Berg Expires 4 February 2027 [Page 3]
Internet-Draft Delegated Refresh Tokens August 2026
1.1. Problem Statement
RFC 8693 defines subject and actor semantics for exchanged tokens,
but it does not specify how those semantics are associated with a
refresh token returned by Token Exchange or preserved in access
tokens subsequently obtained with that refresh token. Without a
profile, implementations can disagree about whether the subject
remains unchanged, whether the complete actor chain is retained,
which client is permitted to refresh, which resources can be
requested, and whether rotation can extend the delegated
authorization indefinitely.
The missing interoperability property is therefore not the existence
of a continuation credential. It is a client-visible way to discover
support for and request that credential, together with common rules
for preserving and enforcing delegated authorization context across
its use. Those properties become important when autonomous agents
and other product components must operate with independently
implemented authorization servers in different trust domains.
1.2. Scope
This specification defines stricter semantics for a refresh token
issued in a successful delegated Token Exchange response. It
specifies the delegated authorization state to which the refresh
token is bound and the rules an authorization server applies when
processing the refresh token grant.
This specification defines the authorization-server metadata member
"delegated_refresh_token_profile_supported" and the Token Exchange
request parameter "request_refresh_token" so that a client can
discover support for and request delegated asynchronous continuation
interoperably. It uses the existing "refresh_token" response
parameter, the existing "refresh_token" grant type, and the existing
"resource" request parameter. It does not define a new token format,
token type identifier, grant type, or token response parameter.
1.3. Non-Goals
* This document does not change refresh-token behavior for grants
other than the profiled delegated Token Exchange.
* This document does not require a refresh token to be a JWT or
otherwise self-contained. The token remains opaque to the client.
* This document does not define generic cross-authorization-server
federation or make a refresh token issued by one authorization
server acceptable to another.
Zhu & Berg Expires 4 February 2027 [Page 4]
Internet-Draft Delegated Refresh Tokens August 2026
* This document does not require every Token Exchange to return a
refresh token. Issuance remains an authorization-server policy
decision.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the OAuth terminology of [RFC6749], the Token
Exchange terminology of [RFC8693], and the resource parameter defined
by [RFC8707].
*delegated Token Exchange*: an RFC 8693 Token Exchange in which the
issued token represents a subject and an actor.
*delegated refresh token*: a refresh token issued in the response to
a delegated Token Exchange and processed according to this profile.
*delegated authorization state*: the subject, complete actor chain,
client binding, permitted resources, maximum scopes, authorization
context, and maximum lifetime associated with a delegated refresh
token.
*acting client*: the OAuth client that performs the delegated Token
Exchange and is represented as the current actor in the resulting
delegated authorization state.
*delegation handle*: an access token whose audience identifies the
acting client, or a resource-server identity securely mapped to that
client, and that the acting client presents as the "subject_token" in
a delegated Token Exchange. The delegation handle carries the
subject and any prior actor chain into the exchange. It is not a new
token type and possession of it does not by itself establish the
identity of the current actor; the authorization server also
validates the handle and authenticates the acting client, including
enforcement of any sender constraint.
*refresh token family*: an initial delegated refresh token and all
replacement refresh tokens derived from it through rotation.
*asynchronous task*: a unit of work identified and tracked by the
acting client that can reach a terminal state independently of the
lifetime of the tokens used to perform it. This profile does not
transmit a task identifier to the authorization server.
Zhu & Berg Expires 4 February 2027 [Page 5]
Internet-Draft Delegated Refresh Tokens August 2026
3. Profile Overview
The profile consists of two protocol operations:
1. The acting client receives an audience-restricted access token
for an on-behalf-of call. That access token is the delegation
handle. The acting client discovers that the authorization
server advertises support for this profile, presents the
delegation handle as the "subject_token" in a delegated RFC 8693
Token Exchange, and includes "request_refresh_token=true" to
request asynchronous continuation. If policy permits
continuation, the authorization server returns an access token
and a refresh token. The refresh token is bound to the delegated
authorization state established by the exchange.
2. Later, the same acting client uses the RFC 6749 refresh token
grant, optionally identifying one target resource using RFC 8707.
The authorization server re-evaluates the delegated authorization
and, if permitted, issues a new audience-specific access token
that preserves the subject and complete actor chain.
A delegated refresh token is intended only for the authorization
server that issued it and MUST NOT be sent to a resource server. The
client MUST treat it as opaque.
4. Issuance During Token Exchange
4.1. Authorization Server Metadata
This specification defines the following authorization-server
metadata member in the metadata structure defined by [RFC8414]:
delegated_refresh_token_profile_supported OPTIONAL. Boolean value
indicating whether the authorization server supports the delegated
refresh-token profile defined by this specification. If omitted,
the value is false.
An authorization server conforming to this profile MUST publish
"delegated_refresh_token_profile_supported" with the value true. A
client MUST verify this metadata value before relying on
"request_refresh_token" or treating a refresh token returned by Token
Exchange as a delegated refresh token under this profile.
Zhu & Berg Expires 4 February 2027 [Page 6]
Internet-Draft Delegated Refresh Tokens August 2026
This explicit discovery signal is necessary because Section 3.2 of
[RFC6749] requires an authorization server to ignore unrecognized
token-request parameters. Without metadata confirmation, a server
that does not implement this profile could ignore
"request_refresh_token" and independently return an ordinary refresh
token under local policy. The presence of "refresh_token" alone
therefore does not prove conformance to this profile.
4.2. Requesting Delegated Continuation
This specification defines the OPTIONAL Token Exchange request
parameter "request_refresh_token". Its value is the case-sensitive
string "true". The parameter indicates that the acting client
requests a refresh token for delegated asynchronous continuation if
authorization-server policy permits.
An authorization server that supports this profile MUST recognize
"request_refresh_token". A value other than "true" MUST be rejected
with "invalid_request". The request is not itself an authorization
grant and does not require the authorization server to issue a
refresh token.
If "request_refresh_token=true" is present and continuation is
authorized, the authorization server returns the refresh token using
the existing "refresh_token" response parameter defined by [RFC6749]
and permitted by Section 2.2.1 of [RFC8693]. If continuation is not
authorized, the authorization server returns the ordinary successful
Token Exchange response without "refresh_token". The client MUST
treat absence of "refresh_token" as denial of continuation and MUST
NOT assume that the successful access-token exchange granted
asynchronous authority.
If the authorization server did not advertise
"delegated_refresh_token_profile_supported" with the value true, the
client MUST NOT treat a returned refresh token as conforming to this
profile. A client that requested continuation before obtaining or
validating metadata MUST NOT use such a refresh token for delegated
continuation and SHOULD revoke it when doing so will not invalidate
authority needed for another purpose.
If "request_refresh_token" is absent, the authorization server MUST
NOT issue a delegated refresh token under this profile. This
prevents creation of a long-lived delegated credential that the
acting client did not request.
The acting client cannot infer the effective lifetime of a delegated
refresh token from the token itself because the token is opaque to
the client. The "expires_in" member in the Token Exchange response
Zhu & Berg Expires 4 February 2027 [Page 7]
Internet-Draft Delegated Refresh Tokens August 2026
describes the primary issued token, not the refresh token. In
addition, authorization-server policy can end continuation before any
configured maximum lifetime. Unless refresh-token expiration is
communicated by another applicable specification, the acting client
does not know how long the refresh token will remain usable.
The acting client MUST request a delegated refresh token only for an
identified asynchronous task that is expected to require continuation
after the current access token or original subject token is no longer
usable. It MUST maintain a one-to-one association in local state
between that task and the current refresh token in its family, and it
MUST NOT reuse the family for another task. This specification
intentionally does not send a business-level task identifier to the
authorization server. The client MUST NOT request a delegated
refresh token speculatively for tasks that can be completed using the
initial access token. These requirements minimize issuance and
retention of long-lived credentials whose effective lifetime the
client cannot otherwise determine.
4.3. Establishing Delegated Authorization State
The acting client performs a Token Exchange request as defined by
Section 2 of [RFC8693]. When the "subject_token" is an access token
whose audience identifies the acting client or a resource-server
identity securely mapped to that client, that access token is the
delegation handle. The authorization server MUST validate the
delegation handle according to its token type, MUST verify that its
audience identifies the authenticated acting client or such a mapped
resource-server identity, and MUST enforce any sender constraint.
Client authentication MUST NOT be treated as satisfying a sender
constraint bound to a different party.
The delegation handle conveys the subject and any prior actor chain
into the exchange; it does not by itself determine the new current
actor. The authorization server derives the current actor from the
authenticated acting client or from an identity securely mapped to
that client. For a delegated exchange, the authorization server MUST
establish:
* the subject represented by the "subject_token";
* the current actor, derived from the authenticated acting client or
from an identity that the authorization server has securely mapped
to that client;
* the complete prior actor chain, if any;
* the acting client's identity;
Zhu & Berg Expires 4 February 2027 [Page 8]
Internet-Draft Delegated Refresh Tokens August 2026
* the resource or resources for which delegated continuation can
issue access tokens;
* the maximum scopes permitted for each resource;
* any authentication context or proof-of-possession requirements;
and
* an absolute maximum delegation lifetime.
If an "actor_token" is supplied, the authorization server MUST
validate it according to [RFC8693] and MUST verify that its actor
identity identifies the authenticated acting client or an identity
securely mapped to that client. The authorization server MUST reject
an actor token that would introduce a different current actor. The
prior actor chain is preserved from the delegated subject token and
MUST NOT be removed or reordered.
The authorization server MUST represent the subject and actor
relationship consistently in the access token issued by the Token
Exchange and in the delegated authorization state associated with any
refresh token returned in the same response.
4.4. Issuing the Refresh Token
If authorization-server policy permits asynchronous continuation, the
authorization server MAY include the existing "refresh_token"
response parameter described by Section 2.2.1 of [RFC8693]. A
refresh token issued under this profile MUST be bound to the
delegated authorization state established by the exchange.
The authorization server MUST bind the delegated refresh token to the
acting client. The current actor recorded in the delegated
authorization state MUST identify that acting client or an identity
that the authorization server has securely mapped to that client.
The authorization server MUST NOT issue a delegated refresh token if
it cannot establish this binding.
Issuance remains discretionary even when requested. A client MUST
NOT assume that a Token Exchange response will contain a refresh
token. Deployments conforming to this profile MUST document the
policy conditions under which delegated refresh tokens can be issued,
as recommended by Section 2.2.1 of [RFC8693].
Zhu & Berg Expires 4 February 2027 [Page 9]
Internet-Draft Delegated Refresh Tokens August 2026
4.5. Token Representation
The representation of a delegated refresh token is an authorization-
server implementation detail. It MAY be an opaque reference or a
protected self-contained token. Regardless of representation, the
client MUST treat the refresh token as opaque and MUST NOT make
authorization decisions based on its contents.
If delegated authorization state is encoded in the token, the
authorization server MUST protect its integrity and MUST maintain any
additional state needed for rotation, replay detection, revocation,
and policy changes. Confidentiality protection SHOULD be used when
the token representation would otherwise disclose subject, actor,
resource, or scope information to the client.
5. Using a Delegated Refresh Token
5.1. Refresh Request
The acting client uses the refresh token grant defined by Section 6
of [RFC6749]. The request MUST contain "grant_type" with the value
"refresh_token" and the delegated refresh token in the
"refresh_token" parameter.
The client SHOULD include exactly one "resource" parameter as defined
by [RFC8707] to identify the downstream resource for which the access
token is requested. If "resource" is omitted, the authorization
server MAY use a default resource only when that default is
unambiguous and within the delegated authorization state; otherwise,
it MUST reject the request with "invalid_target". An authorization
server conforming to this profile MUST NOT issue a single bearer
access token for multiple resources from a delegated refresh request.
The client MAY include "scope". When present, the requested scope
MUST be equal to or narrower than both the scope originally
associated with the delegated refresh token and the scope currently
permitted for the requested resource. When omitted, the effective
requested scope is the scope originally associated with the refresh
token, subject to current policy and resource-specific restriction.
Zhu & Berg Expires 4 February 2027 [Page 10]
Internet-Draft Delegated Refresh Tokens August 2026
POST /token HTTP/1.1
Host: as.example.com
Authorization: <acting client authentication>
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&refresh_token=8xLOxBtZp8
&resource=https%3A%2F%2Fservice-c.example.com
&scope=records.read
Figure 1: Delegated Refresh Request
5.2. Client and Actor Binding
The authorization server MUST authenticate a confidential acting
client and MUST ensure that the delegated refresh token was issued to
that client, as required by [RFC6749]. The authorization server MUST
additionally verify that the authenticated client corresponds to the
current actor in the delegated authorization state.
For a public client, the authorization server MUST use sender-
constrained refresh tokens or refresh token rotation as required by
[RFC9700]. Deployments SHOULD use sender-constrained tokens or
asymmetric client authentication when feasible so that possession of
the refresh token alone is insufficient.
A refresh request MUST NOT substitute another current actor. The
authorization server MUST NOT remove, reorder, or replace any prior
actor in the actor chain.
5.3. Authorization Re-evaluation
For every delegated refresh request, the authorization server MUST:
* validate the refresh token and its client binding;
* check expiration, rotation, replay, and revocation state;
* verify the correspondence between the acting client and the
current actor;
* verify that the requested resource is within the delegated
authorization state;
* verify that the requested scope does not exceed the originally
delegated scope or current policy;
* preserve the subject and complete actor chain;
Zhu & Berg Expires 4 February 2027 [Page 11]
Internet-Draft Delegated Refresh Tokens August 2026
* re-evaluate current authorization-server policy and relevant
subject, client, session, and workflow state; and
* verify that the absolute maximum delegation lifetime has not
elapsed.
A structurally valid and unexpired refresh token does not by itself
require the authorization server to issue an access token. Policy
changes and revocation events apply to subsequent refresh requests.
5.4. Successful Response
If the request is valid and authorized, the authorization server
issues an access token using the response defined by Section 5.1 of
[RFC6749]. The access token MUST be audience-restricted to the
requested or unambiguous default resource and MUST have scope no
broader than the effective requested scope and currently authorized
scope.
The issued access token MUST identify the same subject as the
original delegated Token Exchange. It MUST represent the same
complete actor chain, with the acting client remaining the current
actor. When the access token is a JWT, the authorization server MUST
use the "act" claim and nesting semantics defined by Section 4.1 of
[RFC8693]. For other access token formats, equivalent subject and
actor semantics MUST be available to the resource server.
5.5. Error Handling
If the delegated refresh token is invalid, expired, revoked,
replayed, outside its maximum lifetime, or not bound to the
authenticated client and current actor, the authorization server MUST
reject the request with "invalid_grant" as defined by Section 5.2 of
[RFC6749]. Error descriptions SHOULD avoid revealing whether a
particular subject, actor, workflow, or token family exists.
If the requested resource is absent when required, or is outside the
delegated authorization state, the authorization server MUST reject
the request with "invalid_target" as defined by [RFC8707]. If the
requested scope is too broad, it MUST reject the request with
"invalid_scope" as defined by [RFC6749].
Zhu & Berg Expires 4 February 2027 [Page 12]
Internet-Draft Delegated Refresh Tokens August 2026
6. Rotation and Bounded Lifetime
A successful delegated refresh request that permits further
continuation MUST return a replacement refresh token and MUST
invalidate the refresh token used in the request. The client MUST
discard the previous refresh token and replace it with the returned
token. The authorization server MUST retain enough token-family
state to detect reuse of an invalidated token and respond according
to the refresh token replay guidance in [RFC9700].
If concurrent refresh requests present the same still-valid delegated
refresh token, the authorization server MUST ensure that at most one
request succeeds in a way that advances the refresh token family. It
MUST prevent concurrent requests from creating divergent valid
branches. The authorization server MAY satisfy this requirement
using transactional rotation state or an equivalent mechanism.
As required by Section 6 of [RFC6749], a replacement refresh token
MUST have scope identical to the refresh token presented in the
request. Rotation MUST preserve the subject, complete actor chain,
client binding, permitted resources, maximum scopes, authentication
requirements, and absolute delegation deadline of the refresh-token
family. It MUST NOT add a resource, widen scope, weaken an
authentication requirement, or otherwise expand the delegated
authorization. Current authorization-server policy MAY further
restrict which resources and scopes can be exercised when issuing an
access token without changing the scope of the replacement refresh
token.
The authorization server MUST establish an absolute maximum
delegation lifetime when the initial delegated refresh token is
issued. A replacement refresh token MUST NOT extend that deadline.
Continuation MUST end when the deadline is reached, the refresh token
family is revoked, actor or client binding can no longer be
established, or policy no longer permits continuation.
An authorization server MAY impose additional local limits, including
an inactivity timeout or a maximum number of successful refreshes.
Such limits do not require representation in the refresh token and
are not exposed as protocol parameters by this specification.
Zhu & Berg Expires 4 February 2027 [Page 13]
Internet-Draft Delegated Refresh Tokens August 2026
7. Multi-Hop Example
This non-normative example follows a Service A to Service B to
Service C delegation chain. Service B receives an audience-specific
access token in which the subject is the user and Service A is the
current actor. This access token is the delegation handle for B: it
carries the existing delegated authorization context that B will
present as the "subject_token" in the next Token Exchange.
{
"iss":"https://as.example.com",
"sub":"user-12345",
"aud":"https://service-b.example.com",
"act":{
"sub":"https://service-a.example.com"
},
"scope":"records.read records.write",
"iat":1784678400,
"exp":1784682000
}
Figure 2: Access Token Received by Service B
Service B must call Service C and continue that work asynchronously.
It authenticates as the Token Exchange client and presents its
delegation handle as the "subject_token" in exchange for a Service C
access token. The authorization server validates that the handle is
audience-restricted to Service B, enforces any sender constraint,
derives Service B as the current actor from the authenticated client,
and preserves Service A as the prior actor. Authorization-server
policy permits continuation, so the response includes a delegated
refresh token:
Zhu & Berg Expires 4 February 2027 [Page 14]
Internet-Draft Delegated Refresh Tokens August 2026
POST /token HTTP/1.1
Host: as.example.com
Authorization: <Service B client authentication>
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=eyJ...audience-b-token...
&subject_token_type=
urn:ietf:params:oauth:token-type:access_token
&resource=https%3A%2F%2Fservice-c.example.com
&scope=records.read%20records.write
&request_refresh_token=true
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"eyJ...audience-c-token...",
"issued_token_type":
"urn:ietf:params:oauth:token-type:access_token",
"token_type":"Bearer",
"expires_in":3600,
"scope":"records.read records.write",
"refresh_token":"8xLOxBtZp8"
}
Figure 3: Service B Exchanges for Service C
The authorization server associates the refresh token with subject
"user-12345", current actor Service B, prior actor Service A,
resource Service C, the delegated scopes, the Service B client
binding, and the absolute delegation deadline. The following JSON is
an implementation-neutral illustration of that authorization-server
state. It is not a refresh-token format and is not exposed to the
client:
Zhu & Berg Expires 4 February 2027 [Page 15]
Internet-Draft Delegated Refresh Tokens August 2026
{
"subject":"user-12345",
"actor":{
"sub":"https://service-b.example.com",
"act":{
"sub":"https://service-a.example.com"
}
},
"client_id":"service-b-client",
"permitted_resources":{
"https://service-c.example.com":[
"records.read",
"records.write"
]
},
"maximum_delegation_expires_at":1784707200
}
Figure 4: Illustrative Authorization-Server Delegated State
Later, Service B uses the normal refresh token grant to obtain a
narrower access token for Service C:
POST /token HTTP/1.1
Host: as.example.com
Authorization: <Service B client authentication>
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&refresh_token=8xLOxBtZp8
&resource=https%3A%2F%2Fservice-c.example.com
&scope=records.read
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"eyJ...continued-audience-c-token...",
"token_type":"Bearer",
"expires_in":3600,
"scope":"records.read",
"refresh_token":"Q2al6zV9jB"
}
Figure 5: Service B Continues Delegated Access
Zhu & Berg Expires 4 February 2027 [Page 16]
Internet-Draft Delegated Refresh Tokens August 2026
The new access token retains "user-12345" as the subject, Service B
as the current actor, and Service A as the prior actor. Its audience
is confined to Service C and its scope is narrowed to "records.read".
For a JWT access token, the relevant claims can be represented as
follows:
{
"iss":"https://as.example.com",
"sub":"user-12345",
"aud":"https://service-c.example.com",
"act":{
"sub":"https://service-b.example.com",
"act":{
"sub":"https://service-a.example.com"
}
},
"scope":"records.read",
"iat":1784682000,
"exp":1784685600
}
Figure 6: Continued Access Token Claims
The replacement refresh token remains in the same family and cannot
outlive the original absolute delegation deadline. When the
asynchronous task completes, is cancelled, or reaches a terminal
failure, Service B revokes the current refresh token using the
revocation endpoint defined by [RFC7009]:
POST /revoke HTTP/1.1
Host: as.example.com
Authorization: <Service B client authentication>
Content-Type: application/x-www-form-urlencoded
token=Q2al6zV9jB
&token_type_hint=refresh_token
HTTP/1.1 200 OK
Figure 7: Service B Terminates Delegated Continuation
Service B presents the current token in the rotated family, not the
already-invalidated token used in the preceding refresh request. As
required by Section 9, the authorization server invalidates the
entire family, including any rotated descendants, and Service B
discards its stored copy. No subsequent access token can be issued
from that family.
Zhu & Berg Expires 4 February 2027 [Page 17]
Internet-Draft Delegated Refresh Tokens August 2026
8. Authorization Server Policy
Authorization-server policy MUST govern whether delegated refresh
tokens are issued and continued. At minimum, policy MUST be capable
of considering the acting client, current actor, subject class,
downstream resources, maximum scopes, authentication context, proof-
of-possession requirements, and maximum delegation lifetime.
Policy MUST be applied when the initial refresh token is issued and
re-applied to every refresh request. Implementations MAY
additionally consider workload type, workflow status, subject session
state, transaction state, risk signals, time, or other local
information.
The authorization server MUST create audit records sufficient to link
issuance, refresh, rotation, and revocation decisions to the original
delegated Token Exchange without recording raw refresh tokens.
Implementations SHOULD distinguish structural token failures, replay
detection, and policy re-evaluation failures in protected logs.
9. Revocation
The authorization server MUST support revocation of delegated refresh
tokens using the revocation endpoint defined by [RFC7009] and the
existing "refresh_token" token type hint. It MUST authenticate
confidential clients and any client issued authentication
credentials, and it MUST verify that the refresh token was issued to
the client making the revocation request. For a public client, the
authorization server MUST apply any client-instance or sender-
constraint binding associated with the token and MUST NOT require
authentication that the public client cannot perform.
The acting client MUST maintain a one-to-one association between a
delegated refresh-token family and one asynchronous task and MUST NOT
reuse the family for an unrelated task. The authorization server
scopes and audits each family independently but is not required to
receive or understand the client's business-level task identifier.
Because the acting client cannot rely on knowing the refresh token's
effective lifetime, it MUST use the task's terminal state rather than
an assumed token expiration as the retention boundary. When that
task completes, is cancelled, or reaches a terminal failure, the
acting client MUST promptly revoke the refresh token unless the
authorization server has already invalidated the family. The acting
client MUST then discard all copies of the refresh token.
Revocation of any refresh token in a delegated family MUST invalidate
the entire family, including rotated descendants. The authorization
server SHOULD also invalidate access tokens derived from the family
Zhu & Berg Expires 4 February 2027 [Page 18]
Internet-Draft Delegated Refresh Tokens August 2026
when supported, consistent with [RFC7009]. If immediate invalidation
of derived access tokens is not supported, access tokens issued
through delegated continuation MUST have a short lifetime appropriate
to the task.
Termination of the delegated workflow, termination of relevant
subject authorization or session state, loss or revocation of the
acting client's credential, detected replay, and policy changes that
prohibit continuation SHOULD be supported as family-revocation
triggers.
Revocation state MUST be consulted before any subsequent access token
is issued from the family.
10. Relationship to Existing Specifications
10.1. OAuth 2.0 Refresh Tokens
This document uses the refresh token grant defined by [RFC6749]
without changing its wire format. It adds requirements for the
delegated authorization state established when the refresh token is
issued by RFC 8693 Token Exchange.
10.2. OAuth 2.0 Token Exchange
Section 2.2.1 of [RFC8693] permits a Token Exchange response to
contain a refresh token and asks profiles or deployments to document
issuance conditions. This document is such a profile for delegated,
asynchronous continuation. It also relies on the subject and actor
semantics in Section 4.1 of RFC 8693.
10.3. Continuation Request Signal
The "requested_token_type" parameter in [RFC8693] selects the type of
the primary issued token; it does not request an additional refresh
token in the response. This document defines "request_refresh_token"
so that an acting client can explicitly request asynchronous
continuation. Because unknown token-request parameters are ignored,
the client first verifies the
"delegated_refresh_token_profile_supported" authorization-server
metadata member. The token response continues to use the existing
"refresh_token" parameter.
Zhu & Berg Expires 4 February 2027 [Page 19]
Internet-Draft Delegated Refresh Tokens August 2026
10.4. Authorization Server Metadata
[RFC8414] defines a standard metadata document and a registry for
authorization-server metadata names. The
"delegated_refresh_token_profile_supported" member provides positive
confirmation that the authorization server recognizes
"request_refresh_token" and applies this profile to a refresh token
returned in response.
10.5. Resource Indicators
[RFC8707] defines the "resource" parameter for all access token
requests, including refresh token grants, and permits policy to limit
requested resources to those originally granted. This profile uses
that parameter to select and audience-restrict the downstream access
token.
10.6. OAuth Security Best Current Practice
Implementations MUST follow the refresh-token protection requirements
of [RFC9700], including scope and resource binding and replay
detection for public clients. The requirements in this document are
additional constraints arising from delegated Token Exchange.
11. Security Considerations
A delegated refresh token is a high-value credential because it
permits an acting client to obtain new access tokens on behalf of a
subject without the original subject token or an active user
interaction. Implementations MUST protect it in transit and storage,
bind it to the acting client, prevent resource and scope expansion,
detect replay, support revocation, and enforce the absolute
delegation lifetime.
Because the client generally cannot determine the refresh token's
effective lifetime, retaining it until an assumed expiration can
leave usable delegated authority after the task has ended.
Conservative requesting and prompt revocation at the task's terminal
state are therefore required to reduce the window in which a retained
or stolen refresh token can be abused.
Failure to preserve the complete actor chain can cause a resource
server to authorize a continued request without knowing which service
is currently acting or which services previously participated. The
authorization server MUST therefore derive continued access tokens
from the stored delegated authorization state and MUST NOT rely on
client-supplied actor identity.
Zhu & Berg Expires 4 February 2027 [Page 20]
Internet-Draft Delegated Refresh Tokens August 2026
A stolen refresh token protected only as a bearer credential can
allow an attacker to mint access tokens until detection, revocation,
or expiration. Sender-constrained refresh tokens or asymmetric
client authentication are RECOMMENDED. Rotation is not a substitute
for confidentiality protection.
Refresh tokens and values derived from them MUST NOT be written to
ordinary application or audit logs. Audit records SHOULD use non-
secret correlation identifiers.
12. Privacy Considerations
This profile extends the period during which an acting client can
exercise an existing delegated authorization. Authorization servers
SHOULD issue delegated refresh tokens only when necessary, minimize
permitted resources and scopes, and use the shortest practical
maximum delegation lifetime.
The client treats the refresh token as opaque, which avoids requiring
disclosure of subject and actor information in the credential
representation. If a self-contained representation is used,
confidentiality protection SHOULD prevent unnecessary disclosure to
the client.
Pairwise or otherwise privacy-preserving subject identifiers SHOULD
be used where possible. Authorization and audit state SHOULD be
scoped per task and minimized.
Audit and revocation state can reveal relationships among the
subject, acting services, resources, and workflow. Implementations
SHOULD retain only the information needed for security and
operations. Retention SHOULD be bounded by the workflow lifetime
plus a justified audit window, after which the state SHOULD be
deleted according to a documented policy.
13. IANA Considerations
IANA is requested to register the following parameter in the "OAuth
Parameters" registry:
Parameter name: request_refresh_token
Parameter usage location: token request
Change controller: IETF
Specification document: This document
Zhu & Berg Expires 4 February 2027 [Page 21]
Internet-Draft Delegated Refresh Tokens August 2026
IANA is also requested to register the following authorization-server
metadata name in the "OAuth Authorization Server Metadata" registry
established by [RFC8414]:
Metadata name: delegated_refresh_token_profile_supported
Metadata description: Boolean value indicating support for the
delegated refresh-token profile.
Change controller: IETF
Specification document: This document
This document otherwise uses the existing "refresh_token" response
parameter and grant type from [RFC6749], the existing Token Exchange
response behavior from [RFC8693], the existing "resource" parameter
and "invalid_target" error from [RFC8707], and the existing
"refresh_token" revocation hint from [RFC7009].
14. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
August 2013, <https://www.rfc-editor.org/info/rfc7009>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/info/rfc8693>.
Zhu & Berg Expires 4 February 2027 [Page 22]
Internet-Draft Delegated Refresh Tokens August 2026
[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
February 2020, <https://www.rfc-editor.org/info/rfc8707>.
[RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
"Best Current Practice for OAuth 2.0 Security", BCP 240,
RFC 9700, DOI 10.17487/RFC9700, January 2025,
<https://www.rfc-editor.org/info/rfc9700>.
Acknowledgments
The authors thank Arndt Schwenkschuster for valuable feedback,
including the observation that RFC 8693 already permits refresh-token
issuance for offline Token Exchange scenarios. His feedback led to
reframing this work as a profile of RFC 8693-issued refresh tokens
rather than a new continuation credential.
The authors thank Yaron Zehavi for questions about actor-initiated
delegation, audience restriction, sender constraints, and revocation
that led to clearer definition and validation requirements for the
delegation handle.
Authors' Addresses
Larry Zhu
Atlassian
Email: lzhu3@atlassian.com
Zate Berg
Atlassian
Email: zberg@atlassian.com
Zhu & Berg Expires 4 February 2027 [Page 23]