For Authlete 2.x documentation, see 2.x version.
Preface
This article explains Authlete’s support for RAR and how to use this feature to handle fine-grained permissions. For detailed specifications, please refer to the Overview of the RAR Specification .Configuration
To utilize Authlete’s RAR support, you must configure thetype of authorization details (authorization_details) for both the service and the client.
- Service: Add the supported authorization details types
- Client: Specify the available authorization details types
Service Level Configuration
To configure a list of supported authorizationtypes at the service level:
- Open the Service Settings in the Management Console.
- Navigate to Endpoints > Tokens and Claims > Advanced and to Scope.
- Under Supported Authorization Details Types, add the required
typevalues (e.g.,payment_information,customer_information).
List of supported authorization types by a service
Client Level Configuration
In the Management Console, you can configure the set of requestable authorizationtypes for individual clients:
- Open Client Settings for the specific client.
- Navigate to Endpoints > Advanced and to Scope.
- Under Authorization Details Types, add the
typevalues that the client is allowed to request (e.g.,customer_information). - Click Add to include more types as needed.
authorization_details types the client can declare in its requests.
List of authorization types that a client can request
Examples
Authorization request
You can use RAR regardless of whether or not the request is pushed, or a request object mechanism is used. There are constraints in place for those mechanisms: if the RAR request is very large, it will require clients to use PAR, if you need to make tamper evident, the request object (or JAR) should be used.Request
- URL-encoded
- JAR-wrapped
Response
Authlete extracts and echoes back the authorization details to the AS so they can be used for collecting end user approval.Token request
After the user has approved, an authorization code is generated and sent to the original client. The client will invoke the token endpoint authenticating itself (if required) to the AS, and Authlete’s /auth/token API behind the AS will generate an access token and optionally an ID token (if using openid). Note that the authorization details are not encoded into the ID token.Request
Response
Token introspection Request
Upon receiving an API request with an access token, the resource server utilizes the introspection endpoint to check the authorization granted to that token.Request
The following example demonstrates a resource server conducting an RFC 7662-compliant token introspection request to the authorization server, which subsequently invokes Authlete’s /auth/introspection/standard API.Response
The authorization server extractsresponseContent from the API response to return it to the resource server as the introspection response. This response includes the authorization details (authorization_details) tied to the access token. The resource server uses this information to determine whether to allow or deny the API request.