Skip to main content

Configure scopes

Scopes as stated in OAuth 2.0 specification are made of a string that represent the capabilities the access token (AT) have. It basically set the feature perimeter the AT have on the reseource server (RS), noting that scpoes are RS wise, the definition of the perimeter is specific to the RS that implements the resource scope both on feature than data of each OAuth scope string representation. As an example users:manage:all would give access to managing ability of the users resource with access to all users data scope.

Scope parameters​

label a string that would be displayed discussing the scope, in consent page for instance.

name a string representing the OAuth scope

public set if the scope is public or private, see below

Public vs private scopes​

This server set a distinction between public and private scopes. All the OAuth scopes the server manages are to be listed on the scopes page allowing to create, update, or delete them. Setting the visibility of the scope helps to distinguish scopes that are accessible without restriction (public), and scopes that need specific access to get them (private). That access can be made at client, backend, and user levels.

Manage through User Interface​

The Administration interface gives the ability to create, update and delete clients. Clients are listed through the Scopes > scope list section in the sidebar menu.

scope view

Manage through API​

All client operations are accessible through a REST API following the below description. All client management endpoints are protected with a Bearer token that can be obtained with any OAuth flow. In order to get access, you need to have an access token with the private scope clients:manage:all granted.

Have a look at the API documentation