OAuth Scopes

Scopes define what an access token is authorized to do. The Altium 365 API validates scopes on every request – a token without the required scope for an operation will receive an authorization error.

Scopes are assigned by the platform based on the context in which a token is issued. You don't select scopes manually, but you will encounter them when inspecting tokens and when working with the API. Understanding how scopes are structured helps you interpret what a token is authorized for and reason about access boundaries.

Scopes in a JWT Token

Access tokens are JWTs and can be decoded to inspect their claims. The scope claim lists all scopes the token was issued with. For example, a token issued for Workspace access looks like:

{
  "scope": [
    "openid",
    "profile",
    "a365:workspace:a9a01426-ac92-480e-9f80-97fe0f8ba344"
  ]
}

The scope a365:workspace:{workspace-id} encodes both the access area and the specific Workspace the token is valid for.

Naming Convention

Altium OAuth scopes follow the pattern:

area[:resource][.action]

• area – the broad platform domain (e.g. workspace, global, supply)

• resource – optional; the specific bounded context or data domain within the area (e.g. design, library, app)

• action – optional; the operation type (e.g. read, write, execute)

A few principles behind the naming:

• Area names are domain-based, not product-based. workspace rather than a365, supply rather than octopart.

• Resource names align with bounded contexts and established domain vocabulary.

• Scopes are data-centric, not functionality-centric.

Standard OIDC Scopes

Tokens may also contain standard OIDC scopes used for identity and session management:

Workspace Scopes

Workspace data access is currently represented as a single a365:workspace:{workspace-id} scope covering all Workspace resources. The platform is moving toward a more granular model where access can be scoped to specific bounded contexts:

Each granular scope supports .read and .write actions. The finer-grained model is being rolled out incrementally – it aligns scopes with the API's bounded context model, making it possible to grant an integration access to only the data it actually needs.