Delegated Refresh Tokens for OAuth 2.0 Token Exchange

Internet-Draft	Delegated Refresh Tokens	July 2026
Zhu & Berg	Expires 25 January 2027	[Page]

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.¶

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.¶

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.¶
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.¶

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.¶

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.¶

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 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]. 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;¶
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].¶

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.¶

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;¶
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].¶

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.¶

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:¶

{
  "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 exchanges the access token for a Service C access token. Authorization-server policy permits continuation, so the response includes a delegated refresh token:¶

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:¶

{
  "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

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.¶

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 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.¶

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.¶

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.¶