Authorisation Scopes

This page covers the scope values supported by the Class API.

The Class API supports a subset of the standard OpenID Connect scope values, plus a set of custom values that restrict a request to a specific Business and specify which resources and operations your integration can access.

Supported OpenID Connect values

The Class API supports the following standard scopes, as defined in OpenID Connect Core 1.0.

Scope value	Description
`openid`	Required for all OpenID Connect requests. When specified, an ID token is returned: - In the authorisation response, when `response_type` contains `id_token` - In the token response, when `response_type` contains `code`
`profile`	Includes the following standard claims in UserInfo responses: - `name` - `given_name` - `middle_name` - `family_name` - `gender`
`email`	Includes the `email` claim in ID tokens and UserInfo responses.
`address`	Includes the `address` claim in UserInfo responses.
`phone`	Includes the `phone_number` claim in UserInfo responses.

See Single Sign-On using Class API for ID token structure and validation.

The class_profile scope value

When combined with openid, the class_profile scope allows these additional claims to be retrieved from the UserInfo endpoint:

Field name	Description
`business_name`	The name of the user's business
`business_code`	The code for the user's business in Class
`business_address`	The address of the user's business, in the same format as the standard `address` claim
`business_phone_number`	The phone number of the user's business, in the same format as the standard `phone_number` claim
`class_role`	A comma-delimited list of the user's roles in Class, for example Administrator, Access Controller, adviser

The target scope value

The target scope value specifies which Business the request applies to. It is required whenever any access specifiers are present.

The format is target:context:

Value	Description
`b:`	Requests access to a Business. The user is prompted to select which one.
`b/BUSINESS:`	Requests access to the specific Business with the code `BUSINESS`.

An authorisation flow applies to a single Business. If a user has access to more than one, you must run a separate authorisation flow for each, and store the resulting tokens separately. See Managing Access and Refresh Tokens.

Access specifier scope values

Access specifiers describe which resources your integration can reach and what it can do with them.

Class strongly recommends requesting the minimum set of scopes your integration needs. Users see every scope you request on the consent screen, and unnecessary requests both reduce the chance of approval and increase your exposure if credentials are compromised.

The format is context.resource.operation:

context — the context the resource sits in, for example business or fund. Required for every access specifier.
resource — the resource being requested, for example members, funds, details. If omitted, the request covers all resources within the context.
operation — the operation requested, for example read, maintain, create. If omitted, defaults to read.

Supported access specifiers

Specifier	Description	Implied permissions
`business.fund.list`	List summarised data of funds in the business	—
`business.fund.create`	Create new funds in the business	—
`business.details.read`	View details about users of the business	—
`fund.details.read`	View basic fund details	—
`fund.details.maintain`	View and maintain basic fund details	`fund.details.read`
`fund.member.read`	View member details	—
`fund.member.maintain`	View and maintain member details	`fund.member.read`
`fund.read`	View all fund information	`fund.*.read`
`fund.maintain`	View and maintain all fund information	`fund.*.maintain`

Refer to the API reference for the specific endpoints you intend to call, to determine which access specifiers your integration needs.

Requesting offline_access

The offline_access scope is what gets you a refresh token. Without it, your application must send the user through authorisation again every time the access token expires.

The following requirements apply when requesting it:

offline_access is only supported by the Authorisation Code Flow.
The prompt parameter must be included in the authorisation request, and its value must be consent.
The include_granted_scopes scope value cannot be used alongside offline_access. Requests for offline access must always include the full set of required access specifiers.

Example

A typical scope for a Partner integration reading fund data offline:

class_profile openid offline_access target:b/BUSINESSCODE fund.read

Authorisation Code Flow — how scopes are requested.
Managing Access and Refresh Tokens — what offline_access gets you.
UserInfo Endpoint — which scopes unlock which claims.
Error Codes — troubleshooting invalid_scope.