OAuth-Bereiche

Scopes definieren, wozu ein Access Token berechtigt ist. Die Altium 365 API prüft die Scopes bei jeder Anfrage – ein Token ohne den für einen Vorgang erforderlichen Scope erhält einen Autorisierungsfehler.

Scopes werden von der Plattform abhängig vom Kontext zugewiesen, in dem ein Token ausgestellt wird. Sie wählen Scopes nicht manuell aus, begegnen ihnen jedoch bei der Prüfung von Tokens und bei der Arbeit mit der API. Wenn Sie verstehen, wie Scopes strukturiert sind, können Sie besser nachvollziehen, wozu ein Token berechtigt ist, und Zugriffsgrenzen besser einordnen.

Scopes in einem JWT-Token

Access Tokens sind JWTs und können dekodiert werden, um ihre Claims zu prüfen. Der scope-Claim listet alle Scopes auf, mit denen das Token ausgestellt wurde. Zum Beispiel sieht ein für den Workspace-Zugriff ausgestelltes Token so aus:

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

Der Scope a365:workspace:{workspace-id} codiert sowohl den Zugriffsbereich als auch den spezifischen Workspace, für den das Token gültig ist.

Namenskonvention

Altium-OAuth-Scopes folgen dem Muster:

area[:resource][.action]

• area – die übergeordnete Plattformdomäne (z. B. workspace, global, supply)

• resource – optional; der spezifische abgegrenzte Kontext oder Datenbereich innerhalb des Bereichs (z. B. design, library, app)

• action – optional; der Vorgangstyp (z. B. read, write, execute)

Einige Grundprinzipien hinter der Benennung:

• Bereichsnamen sind domänenbasiert, nicht produktbasiert. workspace statt a365, supply statt octopart.

• Ressourcennamen orientieren sich an abgegrenzten Kontexten und etablierter Domänenterminologie.

• Scopes sind datenzentriert, nicht funktionszentriert.

Standard-OIDC-Scopes

Tokens können auch Standard-OIDC-Scopes enthalten, die für Identitäts- und Sitzungsverwaltung verwendet werden:

Workspace-Scopes

Der Zugriff auf Workspace-Daten wird derzeit als einzelner a365:workspace:{workspace-id}-Scope dargestellt, der alle Workspace-Ressourcen abdeckt. Die Plattform entwickelt sich zu einem granulareren Modell, bei dem der Zugriff auf spezifische abgegrenzte Kontexte begrenzt werden kann:

Jeder granulare Scope unterstützt .read- und .write-Aktionen. Das feinere Modell wird schrittweise eingeführt – es richtet die Scopes am Bounded-Context-Modell der API aus und macht es möglich, einer Integration nur Zugriff auf die Daten zu gewähren, die sie tatsächlich benötigt.