Skip to main content

​
Preface

RFC 9396: OAuth 2.0 Rich Authorization Requests (RAR for short) is a proposed standard extension of OAuth 2.0. It allows clients to use JSON data structures to specify more fine-grained authorization requirements than an existing capability of “scope” parameter. This article describes the support for RAR on Authlete and how you can use it to represent fine-grained permissions.

​
RAR overview

“scope” is a mechanism introduced by OAuth 2 Authorization Framework specification for representing the permissions granted to a third party by a resource owner. You can assign a specific semantic to a scope to represent a permission or an option. For instance: OpenID Connect specification defines the “openid” scope as well as “profile” among others. While “profile” grants to 3rd party access to specific attributes of the user profile, the “openid” scope has a different semantic: it implies an option to generate an ID token and an access permission to UserInfo endpoint. With the broad usage of OAuth 2, new use cases rise and as such new technical solutions are required. The RAR specification addresses scenarios where thrid parties are required to express an intent with more context for user approval, e.g., online payments, file sharing, health exams etc.

​
RAR structure

RAR defines a common JSON structure for the finer grained permissions, where each permission has a “type” attribute, and optionally “locations”, “actions”, “datatypes”, “identifier”,  “privileges”, and others defined by the parties. You can check the structure description under Request parameter “authorization_details” section. The idea is that an authorization server (AS), or an ecosystem that the AS is in, will define different “types” identifiers and their semantics: what do they represent, their structure, their meaning to end users, and association to the other attributes. It will precisely define the permission to be requested to end user. The “locations” attribute has the same concept of the Resource Indicators mechanism, where the location specifies a resource server URI that the permission is about. With the attribute “identifier”, you can point to the specific resource on requesting permissions. While the “locations” indicate a branch of resources, the “identifier” points to a single resource, for short. The “actions” is a big step forward as it can represent for instance: the action on a filesystem, the action on the bank account, an action on medical device, an act on an appliance, a permission on a database, etc. The “datatypes” and “privileges” can be used to represent specifics of the entitlements been requested.

​
Configuration

See Configuring RAR.