Skip to main content

Introduction

the original mechanism on OAuth 2 framework for expressing authorizations is the scopes presented on the token by the subject to the token holder. That allowed many enterprises and adopters to properly secured their environments when there is no ambiguity of the resource that the token is about. Today with the micro service architecture and data partition due to data residency requirements or data sharding, the resource that the grant is about needs to be increasingly precise identified on the request, token and introspection. There are 2 specifications addressing this: the Resource Identifier (RFC 8707) and the Rich Authorization Requests (RFC 9396). This note is about the Resource Identifier specification and the support that Authlete provides. The resource identifier specification extends the authorization requests by introducing the “resource” parameter. This parameter can be included on authorization request parameters, Request Objects or the body of the push authorization requests or token requests.

Basic flow

Authorization Request

The authorization requests, pushed or not and wrapped or not on a Request Object can single or multi valued. The request below is an example of API request to ask Authlete to process an authorization request that includes two resources specified by using the parameter resource.
The response from Authlete includes the resources attribute that will be used by the AS to decide if the authorization request is valid and if the user can grant access to those resources.

Token Request

The AS sends token request content with the authorization code to Authlete.
The response will extract the resources that are granted to the client and include them in accessTokenResources.
Note that the resource list are encoded into the access token (when you are using JWT-Based Access Tokens) and are not included on ID token, as the intent of the ID token is not to be user as Bearer token when accessing the APIs.

Introspection Request

When the access token is presented to a resource server (RS), the RS can use the introspection endpoint to query the resources list and therefore fulfill or not the request. The request below is an example of API request by the AS, asking Authlete API to process an introspection request from the RS to the AS.
A sample response is as follows, note the aud attribute that includes the list of resources that the access token is about.

Narrowing the resource during token request

The Resource Indicators specification creates the option for the client narrowing the list of resources that it is targeting. Let’s say the client has requested the authorization to resources “https://api.example.com/customers/”, “https://api.example.com/orders/” and “https://api.example.com/inventory/”, and the authorization for all those resources is granted. As long as the authorization retains, the client can request an access token restricted to “https://api.example.com/orders/” to run a specific use case and later request another access token to a different resource list. The sequence below of requests shows an API client creating an access token for two resources.
The second request creates an access token specific to the “https://contacts.example.com/”.
And later the same client changes the token to “https://api.example.com/app/.
If you are planning to use this feature, check if the single access token per subject is enabled. if that is the case, the access token will be invalidated when the refresh token is used. In your example, when the second request is done, the access token from the first became invalid. When the 3rd call is done, the access token of the 2nd call is invalidated.