Authorities

Disclaimer: This functionality is work in progress and will be subject to significant changes.

Authorities in the Auth application represent the platform notion of access rights. In OAuth2 terminology the authorities are represented by scopes.

Authorities are defined for:

Scope handling during authorisation request

  1. The Auth application validates the request (client id, password) and whether the scopes requested are allowed for the client application. If not, an error is returned.

  2. The user logs in.

  3. Scope handling:

Application-specific Authorities

Currently the platform supports Authorities that are assigned to Roles (users). For OAuth2 and further configuration, application-specific authorities can also be useful.

The Application-specific Authorities represent an authority or feature that can be requested by an application regardless of the logged-in user.

Currently we have two Application-specific Authority candidates which relate to the Auth application functionality:

Offline Access

is an authority granted to an application that allows the application to request a refresh token along with the regular access token. The refresh token is later used by the application to request a new access token after the initial token's expiration.

Basic Auth

is a temporary mechanism for a fileuploader application which needs to access a legacy basic-auth-protected API. With this authority requested, the created JWT access token contains basic_auth data.

Auth-specific scope helpers

The following scopes do not need to be assigned first, they only affect the way authorities are handled when processing user grants.

Require all scopes

If require_all_scopes is specified the Auth application will authorise the user only if they have all the authorities contained in the request. Normally only intersecting authorities are assigned.

All scopes

If all_scopes is specified then the client application requests all the authorities it has assigned in the platform. Where there are many authorities this saves the developer the work of sending them all in the request.

Collective scopes

The authorisation now supports also scopes, that request that the user must be from certain collective (state51::Collective). The format of the scope is collective_* (the regexp is ^collective_(\w+)$), so for instance these scopes are valid:

Possible scenarios:


Created: Fri Mar 29 2024 01:09:58 GMT+0000 (Coordinated Universal Time)
Build ID: 120390