Ámbitos de OAuth

Los scopes definen lo que un token de acceso está autorizado a hacer. La API de Altium 365 valida los scopes en cada solicitud: un token sin el scope requerido para una operación recibirá un error de autorización.

La plataforma asigna los scopes en función del contexto en el que se emite un token. No se seleccionan manualmente, pero los encontrará al inspeccionar tokens y al trabajar con la API. Comprender cómo se estructuran los scopes le ayuda a interpretar para qué está autorizado un token y a razonar sobre los límites de acceso.

Scopes en un token JWT

Los tokens de acceso son JWT y pueden decodificarse para inspeccionar sus claims. El claim scope enumera todos los scopes con los que se emitió el token. Por ejemplo, un token emitido para acceso al Workspace tiene este aspecto:

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

El scope a365:workspace:{workspace-id} codifica tanto el área de acceso como el Workspace específico para el que el token es válido.

Convención de nomenclatura

Los scopes de OAuth de Altium siguen el patrón:

area[:resource][.action]

• area – el dominio amplio de la plataforma (p. ej., workspace, global, supply)

• resource – opcional; el contexto delimitado específico o dominio de datos dentro del área (p. ej., design, library, app)

• action – opcional; el tipo de operación (p. ej., read, write, execute)

Algunos principios detrás de la nomenclatura:

• Los nombres de las áreas se basan en dominios, no en productos. workspace en lugar de a365, supply en lugar de octopart.

• Los nombres de los recursos se alinean con los contextos delimitados y con el vocabulario de dominio establecido.

• Los scopes se centran en los datos, no en la funcionalidad.

Scopes OIDC estándar

Los tokens también pueden contener scopes OIDC estándar utilizados para la identidad y la administración de sesiones:

Scopes de Workspace

Actualmente, el acceso a los datos del Workspace se representa como un único scope a365:workspace:{workspace-id} que cubre todos los recursos del Workspace. La plataforma está avanzando hacia un modelo más granular, en el que el acceso puede limitarse a contextos delimitados específicos:

Cada scope granular admite acciones .read y .write. Este modelo más detallado se está implementando de forma incremental – alinea los scopes con el modelo de contextos delimitados de la API, lo que permite conceder a una integración acceso únicamente a los datos que realmente necesita.