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:
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.
The user logs in.
Scope handling:
If the application does not request any scopes, or requests no scopes, or application-specific scopes only, then the user is authorised and a JWT access token is generated.
If the application requests a special Auth-specific scope named require_all_scopes, then if the user does not have all the authorities requested by the application then the authorisation request is denied.
Otherwise if the intersection of the application authority sets and user authority set is not empty then the user is allowed to log in and a JWT access token is issued with the subset. It is the responsibility of the client application to adopt the limited authority set.
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:
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.
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.
The following scopes do not need to be assigned first, they only affect the way authorities are handled when processing user grants.
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.
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.
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:
collective_openimp
collecctive_greedbagshop
collective_vilnius
Possible scenarios: