Skip to main content

Access Scopes

An access token scope is a parameter used in OAuth to define the specific permissions or actions that the access token allows when accessing a resource on behalf of a user. Scopes help control the level of access granted to the application, ensuring that the token only has the permissions necessary for the requested operation.

Using Access Scopes​

An application can request one or more scopes. This information:

  • Must be included in the call to the PAR endpoint, OAuth Authorization Endpoint, and OAuth Token Endpoint.

  • Is presented to the user in the consent screen (after the call to the OAuth Authorization Endpoint)

The access token issued to the application is limited to the scopes granted by the user -- for OAuth Authorization Code Flow -- and to scopes requested by the applications in machine-to-machine scenarios using the OAuth Client Credentials Flow.

note

In Raidiam, the scopes your application can request are determined by the application's Role and its associated Metadata.

Roles and Scopes

To request the directory:websitescope, the application needs to have the scope Role Metadata Type assigned with the value set to directory:website.

In Raidiam, all applications are assigned the client_credentials flow and directory:software scope by default.

Note that the application Role is not the value of the scope parameter.

Available Raidiam Access Scopes​

Applications can use the following scopes to access Raidiam APIs:

directory:software​

Used for client-management-related operations like getting a list of all applications registered within the ecosystem or federation, generating Software Statement Assertions, scanning for new Data Receiver applications, retrieval of public certificates, and more.

Additionally, with the directory:software scope, you can perform READ operations on all resources available within the Trust Framework.

Application that has a token with the directory:software scope can perform WRITE operations only on the APIs related to this application. In other words, an application with this scope can request, for example, an application-level certificate only for itself and not for other application.

Requesting the directory:software scope can be done using the client credentials flow without involving the users.

directory:software:cert:management​

A narrower alternative to directory:software for certificate management only. Grants read and write access to certificates belonging to the software statement your application represents.

Requesting the directory:software:cert:management scope can be done using the client credentials flow without involving the users.

directory:software:organisation:cert:management​

Grants read and write access to certificates across your entire organisation, both organisation-level certificates and certificates belonging to any software statement under that organisation, not just the one your application represents.

Requesting the directory:software:organisation:cert:management scope can be done using the client credentials flow without involving the users.

directory:software:organisation:application:management​

Grants read, create, update, and delete access to software statements across your entire organisation (including their authority claims, custom claims, certifications, and assertions), not just the software statement your application represents.

Requesting the directory:software:organisation:application:management scope can be done using the client credentials flow without involving the users.

directory:software:user:management​

Used to create and update authorisation domain users for an organisation, and to read the related user type and system reference data.

Requesting the directory:software:user:management scope can be done using the client credentials flow without involving the users.

directory:software:audit​

Grants read-only access to the Audit API without requiring a Super User, Data Administrator, or Organisation Admin login.

Requesting the directory:software:audit scope can be done using the client credentials flow without involving the users.

directory:website​

Used by applications to perform web-based operations like administering the underlying Trust Framework, onboarding Organisations, and more on behalf of a Super User, Data Administrator -- a Trust Framework Administrator -- or other User Type with appropriate permissions.

Requesting the directory:website scope implies using the OAuth Authorization Code Flow and involves authenticating users and getting their consent.

If your organisation needs to get tokens with the directory:website scope in a machine-to-machine scenario (with the Client Credentials Flow), it can be done by creating a Role that has such metadata configured and assigning it to the Organisation and Application. Contact your Trust Framework Administrator to request such a role.

directory:admin​

Used for privileged administrative operations that go beyond what directory:website or directory:software cover on their own, for example managing Super Users and Data Administrators, registering Certificate Authorities in Reference Data, managing OAuth clients directly, and various platform maintenance operations (such as resetting the JWKS or exporting open data). The exact set of operations available can vary by ecosystem.

Requesting the directory:admin scope can be done using the client credentials flow without involving the users. Access to this scope is restricted; contact your Trust Framework Administrator if your integration needs it.

directory:servicedesk​

Used by service-desk client applications that need read-only access to organisation contacts (including visibility normally reserved for the organisation itself), admin users, and authorisation domain users, along with related authorisation domain and authority reference data, for support and operational purposes. The exact set of data available can vary by ecosystem.

Requesting the directory:servicedesk scope can be done using the client credentials flow without involving the users.

trust_framework_profile​

Scope necessary when using the OAuth Authorization Code Flow and Raidiam Connect as a Single Sign On (SSO) provider to other external platforms.

OpenID Connect Access Scopes​

The following OpenID Connect scopes are available to applications using the OAuth Authorization Code Flow:

openid​

Used to indicate that the application intends to use OIDC to verify the user's identity.

profile​

Used to get basic profile information like the user's name, family name, and more.

email​

Used to get the user's email address.