OAuth Clients

OAuth Clients sind Anwendungen, die sich bei OctoMesh authentifizieren können. Jede Anwendung, die auf OctoMesh-APIs zugreift – ob eine Web-Anwendung, ein Hintergrunddienst oder ein CLI-Werkzeug – muss als Client registriert werden.

Zugriff auf OAuth Clients

Navigieren Sie zu Identity > Clients, um die Oberfläche zur Client-Verwaltung zu öffnen.

Die Liste zeigt alle registrierten Clients:

Spalte	Beschreibung
Client ID	Eindeutiger Bezeichner für den Client
Name	Anzeigename des Clients
Enabled	Ob der Client aktiv ist
URI	Die Basis-URL des Clients

Toolbar-Aktionen

Schaltfläche	Beschreibung
New Client	Eine neue Client-Anwendung registrieren
Search	Clients nach ID oder Name filtern
Export to Excel	Die Client-Liste in eine Excel-Datei exportieren
Export to PDF	Die Client-Liste in eine PDF-Datei exportieren
Refresh Data	Die Client-Liste neu laden

Zeilen- und Kontextaktionen

Aktion	Beschreibung
Edit	Den Client im Bearbeitungsformular öffnen
Delete	Den Client löschen (Kontextmenü, mit Bestätigung)

Einen Client erstellen

Klicken Sie auf New Client, um das Formular zur Client-Erstellung zu öffnen.

Grundinformationen

Feld	Erforderlich	Beschreibung
Client ID	Ja	Eindeutiger Bezeichner (kann nach der Erstellung nicht mehr geändert werden)
Client Name	Ja	Anzeigename für den Client
Client URI	Nein	Basis-URL der Client-Anwendung
Client Secret	Nein	Secret für vertrauliche Clients (Device Code, Client Credentials)

Optionen

Option	Beschreibung
Require Client Secret	Ob sich der Client mit einem Secret authentifizieren muss
Enabled	Ob der Client zur Authentifizierung verwendet werden kann
Offline Access (Refresh Tokens)	Dem Client erlauben, Refresh Tokens anzufordern

Zulässige Grant Types

Wählen Sie aus, welche OAuth-2.0-Grant-Types der Client verwenden darf:

Grant Type	Anwendungsfall
authorization_code	Web-Anwendungen mit browserbasiertem Login
client_credentials	Service-zu-Service-Authentifizierung (kein Benutzerkontext)
urn:ietf:params:oauth:grant-type:device_code	Geräte und CLI-Werkzeuge ohne Browser
refresh_token	Abgelaufene Access Tokens erneuern

Redirect URIs

Konfigurieren Sie, wohin der Identity Service nach der Authentifizierung umleiten darf. Klicken Sie auf die Schaltfläche Add, um Einträge hinzuzufügen.

Jede Redirect URI muss eine vollständige URL sein (z. B. https://myapp.example.com/callback/).

Post Logout Redirect URIs

Konfigurieren Sie, wohin der Identity Service nach der Abmeldung umleitet. Klicken Sie auf die Schaltfläche Add, um Einträge hinzuzufügen.

Allowed CORS Origins

Konfigurieren Sie, welche Origins für Cross-Origin-Anfragen an den Identity Service zulässig sind. Klicken Sie auf die Schaltfläche Add, um Einträge hinzuzufügen.

hinweis

CORS Origins dürfen keinen abschließenden Schrägstrich haben (z. B. https://myapp.example.com).

Allowed Scopes

Konfigurieren Sie, welche API-Scopes der Client anfordern kann. Klicken Sie auf die Schaltfläche Add, um Einträge hinzuzufügen. Gängige Scopes:

Scope	Beschreibung
openid	Erforderlich für OIDC – liefert die Benutzerkennung
profile	Benutzerprofil-Informationen (Name)
email	E-Mail-Adresse des Benutzers
role	Rollen des Benutzers
octo_api	Voller Zugriff auf alle OctoMesh-APIs
octo_api.read_only	Nur-Lese-Zugriff auf alle OctoMesh-APIs

Rollen

Wählen Sie im Feld Roles die Rollen aus, die dem Client direkt zugewiesen werden. Wenn sich der Client über den client_credentials-Flow authentifiziert, werden diese Rollen – zusammen mit allen aus Gruppenmitgliedschaften geerbten Rollen – in sein Access Token aufgenommen, sodass der Client rollengeschützte Endpunkte aufrufen kann. Es wird empfohlen, Berechtigungen über Gruppen statt direkt zuzuweisen.

Gruppenmitgliedschaften

Verwenden Sie das Feld Group Memberships, um den Client zu einer oder mehreren Gruppen hinzuzufügen. Der Client erbt alle Rollen, die diesen Gruppen zugewiesen sind (einschließlich verschachtelter Gruppen), genau wie ein Benutzer.

Klicken Sie auf Save, um den Client zu registrieren, oder auf Cancel, um zu verwerfen.

Einen Client bearbeiten

Klicken Sie in einer Client-Zeile auf Edit, um das Bearbeitungsformular zu öffnen. Die Client ID ist schreibgeschützt. Alle anderen Felder können geändert werden.

Das Client Secret aktualisieren

Im Bearbeitungsmodus wird das bestehende Secret nicht angezeigt (es wird verschlüsselt gespeichert). Um ein neues Secret festzulegen:

1. Klicken Sie auf Set New Secret
2. Geben Sie das neue Secret ein
3. Klicken Sie auf Save

Einen Client löschen

Klicken Sie mit der rechten Maustaste auf einen Client und wählen Sie Delete. Bestätigen Sie die Löschung im Dialog.

gefahr

Das Löschen eines Clients verhindert sofort, dass sich alle Anwendungen, die diese Client ID verwenden, authentifizieren können. Stellen Sie sicher, dass der Client nicht mehr in Verwendung ist, bevor Sie ihn löschen.

Standard-Clients

Die folgenden Clients werden während der Systemeinrichtung automatisch erstellt:

Client ID	Typ	Zweck
octo-cli	Device Code	OctoMesh-Kommandozeilenwerkzeug
octo-idenityServices-swagger	Authorization Code (PKCE)	Swagger-UI der Identity-API
octo-data-refinery-studio	Authorization Code (PKCE)	Data Refinery Studio

Overlay-URIs und template-saubere Exporte

Standard-Clients wie octo-data-refinery-studio werden von einem Blueprint verwaltet: Ihre Redirect-/Post-Logout-/CORS-URIs werden bei jedem Tenant-Lifecycle-Ereignis erneut auf die kanonischen Werte der Umgebung angewendet. Jeder URI-Eintrag trägt eine Source, die entscheidet, ob er dieses erneute Anwenden übersteht:

Source	Hinzugefügt von	Übersteht Blueprint-Re-Apply?
base	Der Blueprint-Seed	Nein – wird immer auf den Blueprint-Wert zurückgesetzt
api	Ein Operator über dieses Studio-Client-Formular oder die API	Ja
overlay:<name>	Ein Entwickler-/Operator-Overlay (z. B. local-dev-Callbacks)	Ja

Overlay-URIs erlauben es einem Entwickler, maschinenlokale Callbacks hinzuzufügen (zum Beispiel http://localhost:4200/auth-callback nach dem lokalen Wiederherstellen eines Produktions-Backups), ohne die wiederhergestellten Produktions-URIs zu zerstören und ohne dass diese lokalen URIs in einen gemeinsam genutzten Export gelangen.

Overlays vor einem Tenant-Backup bereinigen

Wenn Sie einen Tenant aus Tenant Management exportieren (Rechtsklick auf einen Tenant → Backup), bietet der Backup-Dialog ein Kontrollkästchen Clean overlay URIs before export:

• Aktiviert – jede overlay:*-URI auf jedem blueprint-verwalteten Client wird vor dem Erstellen des Dumps entfernt, sodass das resultierende Backup template-sauber und sicher als Blueprint-Seed-Material wieder importierbar ist. base- und api-URIs bleiben erhalten.
• Deaktiviert (Standard) – das Backup erfasst den Tenant exakt so, wie er ist, einschließlich aller Overlay-URIs.

hinweis

Das Bereinigen ist ein einseitiger Vorgang am aktiven Tenant. Wenn Sie die local-dev-Callbacks danach weiterhin benötigen, wenden Sie sie erneut an (ein Operator kann das Werkzeug Apply-IdentityOverlay erneut ausführen, das idempotent ist).

Die vollständige Source-Taxonomie, die CLI-/MCP-Entsprechungen und die Begründung hinter den Overlays finden Sie im Technikleitfaden unter Clients and API Scopes — URI Sources and Lifecycle.