Ambiti OAuth

Gli scope definiscono cosa un token di accesso è autorizzato a fare. L’API di Altium 365 convalida gli scope a ogni richiesta: un token privo dello scope richiesto per un’operazione riceverà un errore di autorizzazione.

Gli scope vengono assegnati dalla piattaforma in base al contesto in cui viene emesso un token. Non si selezionano manualmente, ma li incontrerai quando ispezioni i token e quando lavori con l’API. Comprendere come sono strutturati gli scope ti aiuta a interpretare per cosa un token è autorizzato e a ragionare sui limiti di accesso.

Scope in un token JWT

I token di accesso sono JWT e possono essere decodificati per ispezionarne le attestazioni. L’attestazione scope elenca tutti gli scope con cui è stato emesso il token. Ad esempio, un token emesso per l’accesso al Workspace appare così:

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

Lo scope a365:workspace:{workspace-id} codifica sia l’area di accesso sia lo specifico Workspace per cui il token è valido.

Convenzione di denominazione

Gli scope OAuth di Altium seguono questo schema:

area[:resource][.action]

• area – il dominio generale della piattaforma (ad esempio workspace, global, supply)

• resource – facoltativo; lo specifico contesto delimitato o dominio di dati all’interno dell’area (ad esempio design, library, app)

• action – facoltativo; il tipo di operazione (ad esempio read, write, execute)

Alcuni principi alla base della denominazione:

• I nomi delle aree si basano sul dominio, non sul prodotto. workspace anziché a365, supply anziché octopart.

• I nomi delle risorse sono allineati ai contesti delimitati e al vocabolario di dominio consolidato.

• Gli scope sono incentrati sui dati, non sulle funzionalità.

Scope OIDC standard

I token possono contenere anche scope OIDC standard utilizzati per la gestione dell’identità e della sessione:

Scope del Workspace

L’accesso ai dati del Workspace è attualmente rappresentato come un singolo scope a365:workspace:{workspace-id} che copre tutte le risorse del Workspace. La piattaforma si sta evolvendo verso un modello più granulare, in cui l’accesso può essere limitato a specifici contesti delimitati:

Ogni scope granulare supporta azioni .read e .write. Questo modello più dettagliato viene introdotto progressivamente – allinea gli scope al modello di bounded context dell’API, rendendo possibile concedere a un’integrazione l’accesso solo ai dati di cui ha effettivamente bisogno.