Portées OAuth

Les scopes définissent ce qu’un jeton d’accès est autorisé à faire. L’API Altium 365 valide les scopes à chaque requête – un jeton ne disposant pas du scope requis pour une opération recevra une erreur d’autorisation.

Les scopes sont attribués par la plateforme en fonction du contexte dans lequel un jeton est émis. Vous ne sélectionnez pas les scopes manuellement, mais vous les rencontrerez lors de l’inspection des jetons et lorsque vous travaillez avec l’API. Comprendre la structure des scopes vous aide à interpréter ce qu’un jeton est autorisé à faire et à raisonner sur les limites d’accès.

Scopes dans un jeton JWT

Les jetons d’accès sont des JWT et peuvent être décodés pour examiner leurs claims. Le claim scope répertorie tous les scopes avec lesquels le jeton a été émis. Par exemple, un jeton émis pour l’accès au Workspace ressemble à ceci :

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

Le scope a365:workspace:{workspace-id} encode à la fois la zone d’accès et le Workspace spécifique pour lequel le jeton est valide.

Convention de nommage

Les scopes OAuth d’Altium suivent le modèle suivant :

area[:resource][.action]

• area – le domaine large de la plateforme (par ex. workspace, global, supply)

• resource – facultatif ; le contexte délimité spécifique ou le domaine de données au sein de la zone (par ex. design, library, app)

• action – facultatif ; le type d’opération (par ex. read, write, execute)

Quelques principes derrière ce nommage :

• Les noms de zone sont basés sur le domaine, et non sur le produit. workspace plutôt que a365, supply plutôt que octopart.

• Les noms de ressources s’alignent sur les contextes délimités et le vocabulaire de domaine établi.

• Les scopes sont centrés sur les données, et non sur les fonctionnalités.

Scopes OIDC standard

Les jetons peuvent également contenir des scopes OIDC standard utilisés pour la gestion de l’identité et des sessions :

Scopes du Workspace

L’accès aux données du Workspace est actuellement représenté par un seul scope a365:workspace:{workspace-id} couvrant toutes les ressources du Workspace. La plateforme évolue vers un modèle plus granulaire dans lequel l’accès peut être limité à des contextes délimités spécifiques :

Chaque scope granulaire prend en charge les actions .read et .write. Ce modèle plus fin est déployé progressivement – il aligne les scopes sur le modèle de contexte délimité de l’API, ce qui permet d’accorder à une intégration l’accès uniquement aux données dont elle a réellement besoin.