Complexity of Access Token Privileges Introduced by Grant Management


RFC 8707 Resource Indicators for OAuth 2.0 (published in February, 2021) introduced the resource parameter in order to tie “resources” to an access token as audience.

Combinedly or Independently?

An access token generated by an authorization request including scope=readand resource= will hold information as shown below.

"scope": "read",
"aud": [ "" ],

Introspection Response Format

The following is an example of series of authorization requests with grant management.

  1. Input (authorization request): grant_management_action=update & scope=s2 & resource= & grant_id=g1 / Output (token response): grant_id=g1 & access_token=a2
"scopes": [
{ "scope":"s1", "resource":[""] },
{ "scope":"s2", "resource":[""] }
"scope": "s1 s2",
"aud": [
"scope": "s2",
"aud": [ "" ],
"grant": [
{ "scope":"s1", "resource":[""] }

Token Response Format

The token response format will encounter a similar problem because privileges accumulated by grant_management_action=update cannot be expressed by the scope response parameter.

  1. Give up embedding information about the inherited privileges in a token response and recommend use of the grant management API.

JWT Access Token Format

The format of JWT Access Token (draft-ietf-oauth-access-token-jwt) also will have to deal with the same issue to support Grant Management.


This topic is discussed in the Financial-grade API Working Group of the OpenID Foundation as an issue of Grant Management. Visit “FAPI Issue 455: Impact of grant_management_action=update on AT implementation and introspection” if you are interested.

Co-founder and representative director of Authlete, Inc., working as a software engineer since 1997.