Clients und API-Scopes

In OAuth 2.0 ist ein Client jede Anwendung, die Zugriff im Namen eines Benutzers oder für sich selbst anfordert. API-Scopes definieren, welche Operationen ein Client ausführen darf. Der Identity Service verwaltet beides pro Tenant.

Client-Typen

OctoMesh unterstützt drei Client-Typen, die jeweils für einen anderen Anwendungsfall konzipiert sind:

Authorization Code Client

Für Webanwendungen, in denen ein Benutzer über einen Browser interagiert. Verwendet den Authorization Code Flow mit PKCE.

octo-cli -c AddAuthorizationCodeClient -id "my-web-app" -n "My Web Application" -u "https://myapp.example.com/" -ru "https://myapp.example.com/callback"

Merkmale:

• Benutzer authentifiziert sich über Browser-Weiterleitung
• PKCE erforderlich (für öffentliche SPAs kein Client Secret nötig)
• Unterstützt Refresh Tokens mit dem Scope offline_access
• Benutzer-Claims in den Tokens enthalten

Standardbeispiel: octo-data-refinery-studio — die Data-Refinery-Studio-Webanwendung.

Client Credentials Client

Für die Dienst-zu-Dienst-Kommunikation ohne Benutzerinteraktion. Der Dienst authentifiziert sich mit seiner eigenen Client-ID und seinem Secret.

octo-cli -c AddClientCredentialsClient -id "my-background-service" -n "Background Processor" -s "MyServiceSecret123"

Merkmale:

• Kein Benutzerkontext — Tokens haben keinen sub-Claim
• Authentifiziert sich mit Client-ID + Client Secret
• Umgeht die Tenant-Autorisierungs-Middleware (keine allowed_tenants-Prüfung)
• Verwendet für Hintergrundjobs, Datenpipelines, automatisierte Prozesse

Device Code Client

Für Geräte und CLI-Tools, die keinen Browser direkt öffnen können. Der Benutzer authentifiziert sich auf einem separaten Gerät.

octo-cli -c AddDeviceCodeClient -id "my-iot-device" -n "IoT Sensor Gateway" -s "DeviceSecret123"

Merkmale:

• Gerät zeigt eine URL und einen Code an, den der Benutzer eingeben soll
• Benutzer authentifiziert sich auf einem beliebigen browserfähigen Gerät
• Gerät fragt per Polling den Abschluss ab
• Unterstützt offline_access für langlebige Refresh Tokens

Standardbeispiel: octo-cli — das OctoMesh-Kommandozeilenwerkzeug.

Standard-Clients

Wenn der Identity Service eingerichtet wird, werden diese Clients automatisch erstellt:

Client ID	Typ	Zweck
octo-cli	Device Code	CLI-Tool zur Administration
octo-idenityServices-swagger	Authorization Code (PKCE)	Swagger UI für die Identity-API
octo-data-refinery-studio	Authorization Code (PKCE)	Data Refinery Studio (automatisch provisioniert; RefineryStudioUrl ist standardmäßig https://localhost:4200)
octo-mcpServices-swagger	Authorization Code (PKCE)	Swagger UI für die MCP-Services-REST-API
octo-mcpServices-device	Device Code + Token Exchange	MCP Services: Device-Flow-Login (authenticate-Tool), stiller Token-Refresh und tenantübergreifender Token Exchange (switch_tenant)

Dynamisch registrierte Clients (octo-dcr-*)

Interaktive MCP-Clients wie Claude Code registrieren sich selbst über RFC 7591 Dynamic Client Registration (POST /connect/register), anstatt einen vorkonfigurierten Client zu verwenden. Diese Clients:

• heißen octo-dcr-{random} und sind als dynamisch registriert markiert
• sind bei der Registrierung stark eingeschränkt: Redirect-URIs nur auf Loopback, PKCE, öffentlicher Client (kein Secret), servergebundene Scopes — vom Client übergebene Scopes werden ignoriert
• laufen automatisch ab (Standard 90 Tage) und werden vom Token-Cleanup-Job gekehrt, einschließlich ihrer Spiegelungen pro Tenant
• können wie jeder andere Client aufgelistet werden (octo-cli identity-services client list), sollten aber nicht von Hand bearbeitet werden

Die Registrierung ist standardmäßig aktiviert und kann pro Deployment mit OCTO_IDENTITY__DYNAMICCLIENTREGISTRATION__ENABLED=false deaktiviert werden. Siehe Authentifizierung → Dynamic Client Registration.

URI-Quellen und Lebenszyklus

Jeder Eintrag in den Listen RedirectUris, PostLogoutRedirectUris und AllowedCorsOrigins eines Clients trägt einen Source-Herkunftsmarker, der bestimmt, wie sich der Eintrag über Blueprint-Neuanwendungen und Operator-Konfigurationsänderungen hinweg verhält.

Source-Werte

Source	Verwaltet von	Lebenszyklus	Typische Verwendung
base	Blueprint-Seed	Bei jedem Blueprint-Versions-Bump neu geschrieben	Standard-URIs, die mit dem Dienst ausgeliefert werden
api	REST-API (Studio / octo-cli / direktes HTTP)	Übersteht jede Blueprint-Neuanwendung	Vom Operator hinzugefügte URIs
overlay:<name>	Overlay-Cmdlet	Übersteht jede Blueprint-Neuanwendung	Overlays pro Maschine oder pro Team
family:<name>	Family-Reconciler, der env-Konfiguration liest	Kurzlebig — bei jedem Neustart vollständig regeneriert	Multi-URI-Dev-/Test-Umgebungen

Erhaltung über Blueprint-Neuanwendung hinweg

Wenn der Identity-Dienst neu startet und das System.Identity.Bootstrap-Blueprint erneut anwendet, schreibt der Seed jeden base-basierten Eintrag auf den fünf dienstverwalteten Clients (rtId-Bereich 660…30..34) neu. Der Dienst erfasst jede nicht-base-URI vor der Anwendung und führt sie danach wieder zusammen, sodass:

• Eine URI, die ein Operator über die Studio-Client-UI hinzugefügt hat (Source api), die Neuanwendung übersteht.
• Eine Overlay-Cmdlet-URI (Source overlay:<name>) die Neuanwendung übersteht.
• Eine URI, die der Seed mit demselben Wert erneut behauptet, bei einer Kollision gewinnt — die erfasste Kopie wird verworfen, der Eintrag liest nun Source = "base".

Ohne diesen Mechanismus würde jeder Neustart vom Operator hinzugefügte URIs stillschweigend zerstören.

Den richtigen Mechanismus wählen

URIs erreichen einen blueprint-verwalteten Client über vier Wege. Wählen Sie nach Absicht:

Bedarf	Mechanismus	Wo Sie ihn autoren
URIs, die in jedem Deployment jeder Umgebung existieren	Blueprint base	System.Identity.Bootstrap/seed-data/entities.yaml — Blueprint-Version bumpen
URIs, die pro Umgebung variieren, aber deterministisch aus env-Konfiguration generiert werden (z. B. eine Dev-Server-URL pro Family-Mitglied, im Cluster umgeschaltet)	Family (family:<name>)	{{family.NAME}}-Platzhalter im Seed + OCTO_IDENTITY__URIFAMILIES__* env-Konfiguration
Vom Operator gesegnete dauerhafte Ergänzungen in einer verwalteten Umgebung (z. B. ein einmaliger Partner-Callback, der jeden Neustart überstehen soll)	REST-API (api)	Studio-Client-UI PATCH /v1/clients/...
Entwickler-/maschinenlokale Ergänzungen, die NICHT in gemeinsame Exporte gelangen sollen (z. B. http://localhost:4200/auth-callback)	Overlay (overlay:<name>)	octo-tools/overlays/<name>.yaml + Apply-IdentityOverlay

Wenn eine URI pro Umgebung ihre Form ändert, aber überall existiert, verwenden Sie Family. Wenn sie umgebungsunabhängig und operatorgesteuert ist, verwenden Sie Overlay (maschinenlokal) oder api (dauerhaft in verwalteter Umgebung). Wenn sie Teil der deploybaren Spezifikation auf jedem Cluster ist, legen Sie sie in das Blueprint.

Family-Platzhalter für Multi-URI-Dev-Umgebungen

Das Seed-YAML kann einen {{family.NAME}}-Platzhalter in jeder der drei URI-Listen enthalten. Beim Identity-Start wird der Platzhalter durch einen Eintrag pro registriertem Family-Mitglied aus OctoIdentityServicesOptions.UriFamilies ersetzt, markiert mit Source = "family:NAME". Verwenden Sie dies, wenn dieselbe SPA auf mehreren Ports im selben Cluster läuft — z. B. Angular-Dev-Server :4200 plus Vite-Preview :5173.

Der octo-data-refinery-studio-Client wird mit einem {{family.local-dev}}-Platzhalter in allen drei URI-Listen ausgeliefert. Andere dienstverwaltete Clients können sich durch eine einzeilige Seed-Bearbeitung und einen Blueprint-Versions-Bump anmelden.

Eine Family konfigurieren

# Two members for the local-dev family
Set-Item -Path "env:OCTO_IDENTITY__URIFAMILIES__LOCAL-DEV__0" -Value "https://localhost:4200/"
Set-Item -Path "env:OCTO_IDENTITY__URIFAMILIES__LOCAL-DEV__1" -Value "https://localhost:5173/"

Set-Item wird anstelle der $env:-Kurzschreibweise verwendet, weil PowerShell das - in LOCAL-DEV bei der Kurzschreibweise als Subtraktionsoperator parst.

Reconciliation-Vertrag

Der Reconciler liest bei jedem Neustart die aktuelle env-Konfiguration und bringt den DB-Zustand in Einklang. Ein Blueprint-Versions-Bump ist nicht erforderlich, um eine Konfigurationsänderung zu propagieren:

env-Konfigurationsänderung	DB-Ergebnis beim nächsten Neustart
Neues Mitglied hinzugefügt	Neuer Eintrag mit Source = "family:NAME" materialisiert
Mitglied entfernt	Eintrag aus DB gelöscht
Family vollständig unkonfiguriert	Alle family:NAME-Einträge entfernt
Keine Änderung	Kein DB-Schreibvorgang (idempotent — auch kein Log-Eintrag)

Ein {{family.NAME}}-Platzhalter ist das deklarative Signal „diese Liste will diese Family". Nach der ersten Expansion wird das Signal allein von den vorhandenen family:NAME-Einträgen getragen — der Reconciler liest beide Formen und behandelt sie als gleichwertige Absicht. Eine Family, die auf einer gegebenen Liste weder einen Platzhalter noch vorhandene Einträge hat, bleibt inaktiv; der Reconciler rät nicht, wo er sie hinsetzen soll.

Normalisierung von CORS-Origins

Ein CORS-Origin besteht aus Schema + Host + Port und trägt niemals einen abschließenden Schrägstrich, während Redirect-URIs exakt so abgeglichen werden, wie sie registriert sind. Der Reconciler entfernt daher abschließende Schrägstriche nur beim Schreiben in AllowedCorsOrigins — RedirectUris und PostLogoutRedirectUris behalten ihre abschließenden Schrägstriche. Ein einzelnes Family-Mitglied, das als https://localhost:5173/ konfiguriert ist, löst sich zu https://localhost:5173/ in den Redirect-Listen und https://localhost:5173 in CORS auf, alles aus einem env-Konfigurationswert.

Produktionsstandards

Produktionscluster lassen UriFamilies typischerweise unkonfiguriert. Die Platzhalter lösen sich zu null Einträgen auf, verschwinden aus der Liste, und die URI-Konfiguration ist exakt das, was der Seed ausgeliefert hat — keine umgebungsspezifischen Überraschungen und kein Risiko, dass Dev-only-URIs auf Produktions-Clients landen.

Overlay-URIs anwenden

Das PowerShell-Cmdlet Apply-IdentityOverlay (ausgeliefert in octo-tools) fächert octo-cli -c ApplyClientOverlay über jeden Client auf, der in einer deklarativen YAML-Datei aufgeführt ist. Der Endpunkt dedupliziert nach URI-Zeichenkette (beliebige Source), hängt neue Einträge mit Source = "overlay:<OverlayName>" an und überspringt den DB-Schreibvorgang + Cache-Bust, wenn nichts hinzugefügt wurde — sodass erneute Läufe echte No-Ops sind.

# Default — applies octo-tools/overlays/identity-local-dev.yaml
# to the active octo-cli context's tenant
Apply-IdentityOverlay

# Sanity check before applying
Apply-IdentityOverlay -DryRun

# Personal one-off overlay marked under its own name (so DumpTenant --clean
# strips them without touching the shared local-dev entries)
Apply-IdentityOverlay -OverlayFile ~/dev/gerald-laptop.yaml -OverlayName gerald-laptop

Die gemeinsame Datei octo-tools/overlays/identity-local-dev.yaml ist die kanonische Local-Dev-URI-Menge für jeden blueprint-verwalteten Client. Ports sind gegen die Start-Octo-Zuteilung hartkodiert — keine zweite Template-Substitutionsschicht; eine Quelle der Wahrheit pro Overlay-Datei.

overlayName: local-dev

clients:
  - clientId: octo-data-refinery-studio
    redirectUris:
      - http://localhost:4200/auth-callback
      - http://localhost:4200/silent-renew
    postLogoutRedirectUris:
      - http://localhost:4200/
    allowedCorsOrigins:
      - http://localhost:4200

  - clientId: octo-cli
    redirectUris:
      - http://localhost:5000/callback

  # … other blueprint-managed clients

Ausnahmen pro Entwickler gehen in eine separate Datei, die unter einem separaten Overlay-Namen angewendet wird, sodass sie beim Export unabhängig gefiltert werden können.

Siehe die Apply-IdentityOverlay-Referenz für die vollständige Parametermenge des Cmdlets und die octo-cli ApplyClientOverlay-Referenz für die Form des Aufrufs für einen einzelnen Client.

Overlay-URIs aus Tenant-Dumps entfernen

Bevor Sie einen Tenant-Dump teilen (oder ihn als Blueprint-Seed-Material committen), entfernen Sie die reinen Operator-overlay:*-URI-Einträge, damit sie nicht in andere Umgebungen gelangen. Der Dump selbst ist ein rohes mongodump-Archiv der Tenant-DB, sodass der Filter vor dem Dump statt darin erfolgt — der Operator führt drei separate Befehle aus.

# 1) Strip every overlay:* entry across every blueprint-managed client (destructive)
octo-cli -c CleanClientOverlays -y

# 2) Dump the now-clean tenant
octo-cli -c DumpTenant -tid meshtest -o ./meshtest-clean.dump

# 3) Optional: restore the canonical local-dev overlays (idempotent — no-op if you re-applied between steps)
Apply-IdentityOverlay

CleanClientOverlays ist destruktiv, aber eng begrenzt: Nur Einträge, bei denen Source mit overlay: beginnt, werden entfernt. base-, api- und family:*-Einträge überleben immer. Um einen einzelnen Overlay-Namen anzuvisieren (z. B. ein persönliches gerald-laptop-Overlay zu verwerfen, während die gemeinsame local-dev-Menge erhalten bleibt), übergeben Sie -n <overlayName>:

octo-cli -c CleanClientOverlays -n gerald-laptop -y

Das begleitende Cmdlet Apply-IdentityOverlay ist idempotent — es dedupliziert gegen vorhandene URIs, sodass ein erneuter Lauf nach Schritt 2 alle entfernten Local-Dev-Einträge wiederherstellt, ohne Einträge zu stören, die zwischen den Schritten neu angewendet wurden. Für automatisierte Dump-Pipelines läuft dieselbe dreistufige Anleitung aus einem Skript.

Aus dem Data Refinery Studio

Dieselbe Bereinigung ist in der Studio-UI verfügbar. Wenn Sie einen Tenant sichern (Tenant Management → Rechtsklick auf einen Tenant → Backup), bietet der Backup-Dialog eine Checkbox Clean overlay URIs before export. Wenn Sie sie aktivieren, wird der CleanClientOverlays-Schritt gegen diesen Tenant ausgeführt, bevor der Dump startet, sodass das erzeugte Backup template-sauber ist, ohne den Browser zu verlassen. base-, api- und family:*-URIs werden exakt wie bei der CLI erhalten. Siehe die Seite Studio OAuth Clients — Overlay-URIs und template-saubere Exporte für die operatororientierte Anleitung.

Vom MCP-Server

Für KI-Assistenten-/Automatisierungskontexte werden die Identity-Overlay-Endpunkte auch als MCP-Tools bereitgestellt: apply_client_overlay (Overlay-URIs an einen einzelnen Client anhängen) und clean_client_overlays (overlay:*-Einträge über jeden Client entfernen; als High Risk klassifiziert, sodass es confirm=true erfordert). Sie spiegeln die octo-cli-Befehle eins zu eins.

Architekturhinweis: Ein atomares octo-cli -c DumpTenant --clean-Flag wurde erwogen, aber zurückgestellt — die Dump-Infrastruktur (bot-services + engine MongoDB) sitzt über einer anderen Dienstgrenze als das Schemawissen der identity-services, und eine Überbrückung würde neue dienstübergreifende HTTP-Infrastruktur erfordern. Der eigenständige CleanClientOverlays-Befehl (und seine Studio-Checkbox / sein MCP-Tool) ist die bewusste Alternative: ein separater, expliziter, opt-in Schritt statt eines in den Dump-Lebenszyklus eingebackenen Flags. Die Engine hat ein CloneTenantToTempAsync-Primitiv bereit für den atomaren Pfad, wenn octo-platform-services in Phase 3 die Verantwortung für die übergreifende Tenant-Orchestrierung übernimmt.

Clients verwalten

Auflisten, Aktualisieren, Löschen

# List all clients
octo-cli -c GetClients

# Update a client
octo-cli -c UpdateClient -id "my-web-app" -n "Updated Name" -u "https://new-url.com/"

# Delete a client
octo-cli -c DeleteClient -id "my-web-app"

Client Secrets

Client-Credentials- und Device-Code-Clients benötigen Secrets. Secrets werden als SHA256-Hashes gespeichert.

# Create a new secret with expiration
octo-cli -c CreateApiSecretClient -cid "my-service" -e "2027-12-31" -d "Production secret"

# List secrets
octo-cli -c GetApiSecretsClient -cid "my-service"

# Delete a secret
octo-cli -c DeleteApiSecretClient -cid "my-service" -s "<sha256-value>"

Client-Rollen und Gruppenmitgliedschaft

Einem Client können Rollen und Gruppenmitgliedschaften mit derselben Semantik wie einem Benutzer zugewiesen werden — sodass eine Maschine-zu-Maschine-Identität, die den client_credentials-Flow verwendet, als autorisierter Aufrufer gegen rollengeschützte Endpunkte agieren kann (zum Beispiel eine HTTP-ausgelöste Pipeline). Dies ergänzt Scopes: Ein Scope steuert, welche API-Oberfläche das Token erreichen darf, während eine Rolle die Autorisierung innerhalb dieser Oberfläche steuert.

Rollen-Claims im Access Token

Wenn ein client_credentials-Token ausgestellt wird, löst der Identity Service die effektiven Rollen des Clients auf — seine direkt zugewiesenen Rollen plus alle über Gruppenmitgliedschaften (einschließlich verschachtelter Gruppen) geerbten Rollen — und gibt sie als role-Claims im Access Token aus. Die Claim-Form ist identisch mit einem Benutzer-Token, sodass Konsumenten wie der FromHttpRequest-Trigger-Node und die Backend-Autorisierungs-Middleware keinen clientspezifischen Codepfad benötigen.

info

Nur der client_credentials-Grant ist betroffen. Andere Flows (authorization_code, device_code, refresh_token) tragen die Rollen-Claims des angemeldeten Benutzers bereits über den Profile Service.

Rollen direkt zuweisen

# Assign a role to a client (by role name)
octo-cli -c AddClientToRole -id "my-service" -r "DataAnalyst"

# Replace the full set of directly-assigned roles (by role id)
octo-cli -c UpdateClientRoles -id "my-service" -rids "<role-id-1>,<role-id-2>"

# Remove a role (prompts for confirmation; add -y to skip)
octo-cli -c RemoveClientFromRole -id "my-service" -r "DataAnalyst"

Rollen über Gruppen zuweisen (empfohlen)

Wie bei Benutzern ist der empfohlene Ansatz, Berechtigungen über Gruppen zu verwalten. Fügen Sie den Client einer Gruppe hinzu, und er erbt alle Rollen der Gruppe. Ein Client wird über seine Runtime-ID (RtId, aus GetClient) hinzugefügt:

octo-cli -c AddClientToGroup -id "<group-rtid>" -cid "<client-rtid>"
octo-cli -c RemoveClientFromGroup -id "<group-rtid>" -cid "<client-rtid>"

Beide Oberflächen sind auch im Data Refinery Studio-Client-Formular verfügbar (Roles + Group Memberships) sowie als MCP-Tools. Client-Rollen-/Gruppenzuweisungen können zusätzlich deklarativ im Identity-Blueprint-Seed ausgedrückt werden, sodass sie ein Re-Seeding überstehen.

API-Scopes

API-Scopes steuern, welche Operationen ein Client ausführen kann. Einem Client muss ein Scope gewährt werden, damit er ihn in Token-Anfragen aufnehmen kann.

Standard-API-Scopes

OctoMesh verwendet eine einheitliche Menge von API-Scopes, die über alle Dienste geteilt wird:

Scope	Zugriffsebene	Beschreibung
octo_api	Vollzugriff	Lese- und Schreibzugriff auf alle OctoMesh-APIs
octo_api.read_only	Nur lesend	Nur-Lese-Zugriff auf alle OctoMesh-APIs

API-Scopes verwalten

# List all scopes
octo-cli -c GetApiScopes

# Create a custom scope
octo-cli -c CreateApiScope -n "myAPI.admin" -dn "Admin Access" -d "Full administrative access" -e true

# Update a scope
octo-cli -c UpdateApiScope -n "myAPI.admin" -dn "Updated Name"

# Delete a scope
octo-cli -c DeleteApiScope -n "myAPI.admin"

Scopes an Clients gewähren

Verwenden Sie AddScopeToClient, um einem Client Zugriff auf bestimmte API-Scopes zu gewähren:

# Grant asset repository access
octo-cli -c AddScopeToClient -id "my-web-app" -n "octo_api"

# Grant read-only API access
octo-cli -c AddScopeToClient -id "my-web-app" -n "octo_api.read_only"

Ein Client kann nur Scopes anfordern, die ihm gewährt wurden. Wenn ein Client einen Scope anfordert, den er nicht hat, enthält das Token diesen Scope nicht.

API-Ressourcen

API-Ressourcen gruppieren verwandte Scopes und können ihre eigenen Secrets haben (für die API-Introspektion).

Standard-API-Ressourcen

Ressource	Anzeigename	Beschreibung	Scopes
octoAPI	Octo API	Einheitlicher Zugriff auf alle Octo-Plattform-APIs	octo_api, octo_api.read_only

API-Ressourcen verwalten

# List all resources
octo-cli -c GetApiResources

# Create a resource with scopes
octo-cli -c CreateApiResource -n "myAPI" -dn "My Custom API" -d "Custom API" -s "myAPI.read,myAPI.write"

# Update a resource
octo-cli -c UpdateApiResource -n "myAPI" -dn "Updated API Name"

# Delete a resource
octo-cli -c DeleteApiResource -n "myAPI"

API-Ressourcen-Secrets

API-Ressourcen können Secrets für die Token-Introspektion haben:

# Create a secret
octo-cli -c CreateApiSecretApiResource -n "myAPI" -e "2027-12-31" -d "Introspection secret"

# List secrets
octo-cli -c GetApiSecretsApiResource -n "myAPI"

# Delete a secret
octo-cli -c DeleteApiSecretApiResource -n "myAPI" -s "<sha256-value>"

Identity-Ressourcen

Identity-Ressourcen definieren, welche Benutzer-Claims in Identity Tokens enthalten sind. OctoMesh konfiguriert diese standardmäßig:

Ressource	Claims	Zweck
openid	sub	Erforderlich für OIDC — Benutzerkennung
profile	name, given_name, family_name	Benutzerprofilinformationen
email	email, email_verified	E-Mail-Adresse des Benutzers
role	role	Benutzerrollen (benutzerdefinierte Ressource)

Wenn ein Client scope=openid profile email role anfordert, enthält das resultierende Token alle Claims aus diesen Identity-Ressourcen sowie die OctoMesh-spezifischen Claims (tenant_id, allowed_tenants).

Beispiel: Eine neue Webanwendung registrieren

Vollständiger Workflow zum Hinzufügen einer neuen Webanwendung zu OctoMesh:

1. Erstellen Sie den Client:

   octo-cli -c AddAuthorizationCodeClient -id "my-dashboard" -n "My Dashboard App" -u "https://dashboard.example.com/" -ru "https://dashboard.example.com/auth/callback"

2. Gewähren Sie die erforderlichen Scopes:

   octo-cli -c AddScopeToClient -id "my-dashboard" -n "octo_api"

3. Verifizieren Sie den Client:

   octo-cli -c GetClients

Die Anwendung kann nun Benutzer über Authorization Code + PKCE authentifizieren und alle OctoMesh-APIs aufrufen.

Siehe auch

• octo-cli — AddAuthorizationCodeClient und verwandte Client-Befehle (AddClientCredentialsClient, AddDeviceCodeClient, GetClients, UpdateClient, DeleteClient, AddScopeToClient) — CLI-Befehle zur Client-Verwaltung
• octo-cli — CreateApiSecretClient und verwandte Secret-Befehle (GetApiSecretsClient, UpdateApiSecretClient, DeleteApiSecretClient) — Client-Secrets von der CLI aus verwalten
• octo-cli — AddClientToRole und verwandte Client-Rollen-/Gruppen-Befehle (RemoveClientFromRole, UpdateClientRoles, AddClientToGroup, RemoveClientFromGroup) — einem Client Rollen und Gruppenmitgliedschaften zuweisen
• octo-cli — GetApiScopes und verwandte Scope-Befehle (CreateApiScope, UpdateApiScope, DeleteApiScope) — API-Scopes von der CLI aus verwalten
• octo-cli — ApplyClientOverlay — URIs an einen blueprint-verwalteten Client anhängen, ohne sie bei der nächsten Blueprint-Neuanwendung zu verlieren
• octo-cli — CleanClientOverlays — overlay:*-URI-Einträge von jedem Client entfernen (oder nur ein Overlay nach Namen) — destruktive Bereinigung vor bereinigten Tenant-Dumps
• Apply-IdentityOverlay — PowerShell-Cmdlet, das den Overlay-Endpunkt aus einer deklarativen YAML-Datei ansteuert
• Studio OAuth Clients — das Data-Refinery-Studio-Client-Formular + die Backup-Option „Clean overlay URIs before export"
• MCP-Tools apply_client_overlay / clean_client_overlays — dieselben zwei Overlay-Operationen, die KI-Assistenten über den OctoMesh-MCP-Server bereitgestellt werden