JSON:API Permission Access

JSON:API Permission Access provides an additional permission on JSON:API based routes. Without this permission, users (other than administrators) will be unable to retrieve data from these endpoints. This can be useful when pairing with Consumers and Simple OAuth as you need to attach scope(s) to specific role(s), which can have very specific permissions...like this one 🙂

Features

When you enable JSON:API there is no straightforward way to provide access controls on various routes. This can potentially lead to exposing some data that you do not want to expose, i.e. /jsonapi/user/user.

From the JSON:API module security considerations documentation, we can see that:

• Entity Access is respected.
• Field Access is respected.
• When modifying data, validation constraints are respected.
• The internal flag is respected (see documentation about how it can be set on an entity type definition, field definition or property definition).

Adjusting the permissions on entities/fields for specific roles can be cumbersome so this aims to provide a simple layer on top of all that for easy control.

Post-Installation

After installation, any user who attempts to visit JSON:API based routes will be met with an access denied if they do not have the specified permission.

You can add the permission to any role you would like to allow access from the /admin/people/permissions page.

Additional Requirements

None.

Recommended modules/libraries

• Simple OAuth: This module defines scopes which are attached to specific roles. This permission can be assigned to a specific role, which can then be used as part of a scope for OAuth based access flows.

Similar projects

• Drupal REST & JSON API Authentication: This module provides Basic authentication (based on Drupal users) out of the box as well as API Key authentication, but places more advanced features such as OAuth behind a paywall. With JSON:API Permission Access + Simple Oauth + Consumers this can be accomplished at no cost.
• Jsonapi Role Access: This module does a very similar implementation except it introduces added complexity with separate configuration when this can be achieved through the standard permission handling methods.