Resource Indicator Response Parameter for OAuth 2.0

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

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 3 September 2026.¶

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

"Resource Indicators for OAuth 2.0" [RFC8707] defines the resource request parameter for use in authorization requests and access token requests, enabling a client to signal the target protected resource(s) to an authorization server. However, it does not define a corresponding response parameter that would allow the authorization server to communicate back to the client which resource(s) the issued access token is actually for.¶

Without a response parameter, a client cannot reliably determine the effective resource(s) of an issued access token when the authorization server restricts the token to a subset of the requested resources, or when it applies a default resource policy in cases where the client did not include the resource parameter in its request.¶

This document addresses that gap by defining the resource parameter for use in access token responses.¶

2. Access Token Response Resource Parameter

In access token responses, the resource parameter is represented as a JSON array of strings, unlike the repeated form-encoded or query parameter used in requests defined in [RFC8707].¶

The resource parameter defined for an access token response (Section 5.1 of [RFC6749]) is used to indicate to the client the resource(s) which an issued access token is for.¶

resource:

OPTIONAL, if identical to the resource value(s) requested by the client; otherwise, REQUIRED. Its value is a JSON array of strings, where each string is an absolute URI as specified by Section 4.3 of [RFC3986], identifying a protected resource for which the access token is valid. The array MUST contain at least one value.¶

[[TODO: (#1) Should the response use resource (a JSON string) when a single resource is indicated and resources (a JSON array of strings) when multiple are indicated instead?]]¶

The resource response parameter serves a similar role to the scope response parameter defined in Section 5.1 of [RFC6749]: it informs the client when the resource(s) associated with the issued access token differ from what the client requested. This can occur when the authorization server restricts the token to a subset of the requested resources, or when the authorization server applies a default resource policy in cases where the client did not include the resource parameter in its request.¶

If the client requested access to multiple resources but the authorization server issues an access token that is restricted to a subset of those resources, the authorization server MUST include the resource parameter in the response to inform the client of the effective resource(s). The client can then make additional token requests for the remaining resources as needed.¶

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
   "access_token": "_Q-oyRuYqHlj_ZgXwuS54thQm_L5GhB3XH20cVtYfq",
   "token_type": "Bearer",
   "expires_in":3600,
   "refresh_token": "4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2",
   "scope": "calendar",
   "resource": ["https://cal.example.com/"]
}

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
   "access_token": "_Q-oyRuYqHlj_ZgXwuS54thQm_L5GhB3XH2cVtYfqh",
   "token_type": "Bearer",
   "expires_in":3600,
   "refresh_token": "4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2",
   "id_token": "eyJhbGciOiJSUzI...",
   "scope": "openid email profile",
   "resource": ["https://server.example.com/userinfo"]
}

3. Security Considerations

This document inherits the security considerations of [RFC8707].¶

Knowledge of the resource(s) for which an access token is valid does not introduce new security concerns for the client. The resource response parameter merely makes explicit information that the client either already requested or that the authorization server determined based on its policy.¶

4. Privacy Considerations

The resource response parameter conveys information about the resource(s) associated with an access token back to the client. Since the client either requested these resources or they were determined by authorization server policy, no new privacy-sensitive information is disclosed by this parameter.¶

5. IANA Considerations

6. References

Acknowledgments

The original "Resource Indicators for OAuth 2.0" specification [RFC8707] was authored by Brian Campbell, John Bradley, and Hannes Tschofenig.¶

Document History

draft-skokan-oauth-resource-response-02¶

• Added guidance on scope or policy determined resource values¶

draft-skokan-oauth-resource-response-01¶

draft-skokan-oauth-resource-response-00¶

• Initial draft defining the resource access token response parameter¶

Author's Address