Verbundene Apps (OAuth-Verbindungen)

Mit Uptimeify kannst du Drittanbieter-Apps (wie Claude Desktop / Claude.ai) per MCP-OAuth verbinden. Mit diesen beiden Endpunkten kann der angemeldete Nutzer seine eigenen Verbindungen auflisten und widerrufen. Sie stehen hinter der Seite Einstellungen → Verbundene Apps im Dashboard.

Beide Endpunkte sind session-authentifiziert (Browser-Cookie), nicht token-basiert: sie gehören nicht zur wsm_-/wsma_-API-Token-Oberfläche, und jede Operation ist strikt auf die eigenen Verbindungen des Aufrufers beschränkt.

So verbinden sich ClientsAnkerlink kopieren

Ein Client meldet sich auf einem von zwei Wegen an: mit einem Client ID Metadata Document (CIMD, bevorzugt), bei dem die client_id eine HTTPS-Adresse ist, unter der der Client seine eigenen Metadaten bereitstellt, oder über die dynamische Client-Registrierung unter /api/auth/oauth2/register. Die Metadaten des Autorisierungsservers unter /.well-known/oauth-authorization-server nennen alle Endpunkte; Autorisierung und Token-Tausch liegen unter /api/auth/oauth2/.

Access-Tokens sind signierte JWTs, gebunden an die Ressource https://uptimeify.io/mcp, und eine Stunde gültig. Mit offline_access bekommt der Client zusätzlich ein Refresh-Token, sieben Tage gültig und bei jeder Verwendung ersetzt. Ein Widerruf wirkt sofort, auch für ein Access-Token, das noch nicht abgelaufen ist.

ScopesAnkerlink kopieren

Eine Verbindung trägt Scopes, und jeder davon deckt genau einen Bereich deiner Monitoring-Daten ab. Insgesamt gibt es vierzehn: sieben Lese-Scopes plus deren Sammel-Alias mcp:read, und sechs Schreib-Scopes, mit denen die Verbindung Daten in diesem Bereich ändern statt nur ansehen darf.

Lese-ScopesAnkerlink kopieren

mcp:read ist der Scope, den ein Client anfragt, wenn er Lesezugriff ohne Bereichsangabe will. Er ist auf die drei Betriebsbereiche eingefroren, die es bei seiner Einführung gab (Monitore, Vorfälle, Prüfhistorie), und wächst mit keinem neuen Bereich mit: die vier neueren Lesebereiche -- Alarme, Statusseiten, Organisation, Abrechnung -- müssen namentlich angefragt werden, erst dann bietet die Zustimmungsseite sie an. Verbindungen aus der Zeit vor den feinen Scopes tragen ihn ebenfalls und bleiben unverändert.

Schreib-ScopesAnkerlink kopieren

Alle sechs stehen heute für echte Werkzeuge: mcp:monitors:write schaltet sechs Tools frei (pausieren, fortsetzen, umbenennen, Prüfintervall ändern, einen Monitor anlegen und löschen), mcp:incidents:write vier (bestätigen, lösen, ein Update posten, einen manuellen Incident löschen), mcp:maintenance:write drei (ein Wartungsfenster anlegen, ändern und löschen), mcp:statuspages:write acht (eine Statusseite anlegen, ändern und löschen, ihre Gestaltung ändern, sowie eine eigene Domain hinzufügen, verifizieren, aktivieren und löschen), mcp:alerts:write drei (einen Benachrichtigungskanal anlegen, ändern und löschen; anlegen geht nur für email- und sms-Kanäle, und keines der drei vergleicht vor dem Schreiben einen Zustand) und mcp:organization:write neunzehn -- fünf für Etiketten, drei für eigene Felder, drei für geplante Berichte, eines für ein Mitglied und sieben für Kundschaften samt ihren überwachten Domains und IP-Adressen. Die vollständige Liste mit allem, was jedes Tool tut, steht unter Authentifizierte Tools (schreibend). Drei Dinge bietet dieser Bereich bewusst nicht, was der Scope-Name auch nahelegen mag: es gibt kein Werkzeug, das ein Mitglied anlegt, und keines, das eines löscht, sondern nur eines, das ein bestehendes ändert oder deaktiviert; es gibt keine Sammel-Kundenpflege und keinen Weg, einen Bericht von Hand zu versenden; und die Stammdaten der Organisation lassen sich gar nicht ändern. Zwei weitere Punkte lohnen sich, bevor du ihn gewährst: delete_custom_field löscht kein Feld, es nimmt es aus den Formularen und der Kundentabelle, während die Definition und jeder erfasste Wert in der Datenbank bleiben, und delete_tag streicht das Etikett aus jedem Wartungsfenster, das es benutzt hat, was ein Fenster ganz ohne Umfang zurücklassen kann. update_user und update_customer sind die einzigen zwei Werkzeuge des Bereichs, die vor dem Schreiben den Zustand eines Datensatzes vergleichen, und auch das nur, wenn die Verbindung zusätzlich mcp:organization:read hält. Die Zustimmungsseite bietet alle sechs Schreibbereiche als eigene Häkchen an, getrennt von den Lesebereichen gruppiert, damit ein Haken dort eine bewusste, eigene Entscheidung ist.

Ob ein Schreib-Scope überhaupt etwas bewirkt, hängt zusätzlich von der Bereitstellung ab, unabhängig davon, welche Scopes es gibt. Schreib-Werkzeuge werden nur registriert, wenn die Bereitstellung sie eingeschaltet hat; ist das nicht der Fall, kann eine Verbindung, die jeden Scope aus dieser Tabelle hält, trotzdem nichts anlegen, ändern oder löschen. Frag die Person, die deine Uptimeify-Instanz betreibt, statt es allein aus dem Scope-Katalog zu schließen.

Bewusst fehlt mcp:billing:write und jeder Scope für Zugangsdaten -- nichts hier kündigt ein Abo, ändert ein Paket oder prägt ein eigenes API-Token.

Ein Häkchen bei einem Schreib-Scope auf der Zustimmungsseite hakt automatisch auch seinen gleichnamigen Lese-Zwilling mit an (mcp:monitors:write hakt mcp:monitors:read mit an, mcp:incidents:write entsprechend mcp:incidents:read): Die Schreib-Werkzeuge vergleichen den aktuellen Zustand eines Datensatzes, bevor sie schreiben, um einen Schreibvorgang nicht zu wiederholen, den ein Modell schon gemacht hat, und dieser Vergleich braucht Lesezugriff auf dieselben Daten. mcp:maintenance:write ist der einzige Schreib-Scope ohne Zwilling, und das ist Absicht -- Wartungsfenster werden unter mcp:statuspages:read gelesen und bleiben dort.

Alle 14 Scopes -- die sieben Lesebereiche, der mcp:read-Alias und die sechs Schreibbereiche -- stehen in den OAuth-Discovery-Dokumenten (/.well-known/oauth-authorization-server und /.well-known/oauth-protected-resource). Ein Client muss sie also nicht kennen, er findet sie. Fragt ein Client gar keinen MCP-Scope an, weisen wir ihn nicht ab: mcp:read kommt zur Anfrage dazu, damit die Zustimmungsseite weiterhin die drei Betriebsbereiche anbietet, die dieser Alias deckt, und jeder davon abwählbar bleibt. Eine Anfrage, die bereits einen MCP-Scope nennt, bleibt unangetastet und wird nie aufgeweitet.

Ein Token sieht nur die Werkzeuge, deren Scope ihm gewährt wurde. Eine Verbindung mit ausschließlich mcp:incidents:read listet in tools/list genau list_incidents und kein weiteres kontogebundenes Werkzeug: der Rest ist nicht bloß versteckt, sondern gar nicht vorhanden, und ein Aufruf trotzdem wird abgewiesen. Ein Token ganz ohne MCP-Scope sieht keine kontogebundenen Werkzeuge; eine Verbindung neu zu autorisieren ersetzt sie durch einen echten, verengbaren Scope. Die anonymen Prüfwerkzeuge auf /mcp (DNS, TLS, WHOIS und die übrigen) brauchen kein Token und stehen außerhalb dieses Systems.

Bei einem Werkzeug hängt nicht nur die Sichtbarkeit, sondern die Antwort selbst an einem zweiten Scope: billing_summary nennt die Kunden seiner Verbrauchsaufschlüsselung nur dann beim Namen, wenn neben mcp:billing:read auch mcp:organization:read freigegeben wurde. Mit der Abrechnung allein trägt die Aufschlüsselung öffentliche Kennungen und Verbrauchswerte und keine Namen -- die Kundenliste gehört zum Organisationsbereich und kommt nicht über den Verbrauch zurück.

ZustimmungAnkerlink kopieren

Jede Autorisierung führt über eine Zustimmungsseite. Sie nennt die anfragende Anwendung, nennt das Konto, mit dem sie verknüpft wird, und bietet jeden Lese- und Schreibbereich als eigenes Häkchen an, wobei die Schreibbereiche getrennt von den Lesebereichen gruppiert sind, damit das Gewähren eines Schreib-Scopes eine bewusste, eigene Entscheidung ist. Ein abgewähltes Häkchen entfernt den Scope, bevor der Autorisierungscode entsteht: das ausgegebene Token ist dann enger als das, was der Client angefragt hat.

prompt wird bei uns auf consent gezwungen. Eine Autorisierungsanfrage kann die Seite also weder durch Weglassen des Parameters noch durch einen anderen Wert überspringen. Die einzige Anfrage, die wir nicht umschreiben, ist prompt=none: sie bedeutet „zeige keine Oberfläche", und da wir ohne Zustimmung nichts mehr ausgeben, ist die Antwort der Fehler-Redirect, den OpenID Connect dafür vorsieht, statt einer Seite. Ohne Sitzung lautet der Code login_required, mit Sitzung consent_required.

Die Seite schickt ihre Auswahl zusammen mit der signierten Autorisierungsanfrage, mit der sie geöffnet wurde, an einen session-gebundenen Endpunkt. Der prüft die Auswahl gegen das, was der Client angefragt hat, und reicht sie erst dann an den Autorisierungsserver weiter, der die Signatur prüft. Dieser Endpunkt gehört nicht zur öffentlichen API-Oberfläche; seine Fehlercodes stehen unter Fehlercodes.

Verbindungen auflistenAnkerlink kopieren

GET /api/oauth/connections

Liefert die eigenen, aktiven OAuth-Verbindungen des Aufrufers, einen Eintrag pro verbundenem Client. „Aktiv" bedeutet, dass die Zustimmung des Nutzers für diesen Client noch besteht; Widerrufen entfernt sie. Ohne Verbindungen liefert der Endpunkt ein leeres Array.

Query-ParameterAnkerlink kopieren

Beispiel (cURL)Ankerlink kopieren

curl -X GET "$BASE_URL/api/oauth/connections?envelope=items" \
  -H "Cookie: $SESSION_COOKIE" \
  -H "Accept: application/json"

AntwortAnkerlink kopieren

{
  "items": [
    {
      "client_id": "claude-desktop",
      "client_name": "Claude",
      "connected_at": "2026-06-01T09:12:00.000Z",
      "last_active": "2026-07-20T14:03:00.000Z",
      "scope": "read-only"
    }
  ],
  "total": 1,
  "page": 1,
  "perPage": 1
}

Listenform: Mit envelope=items kommt die Liste als { items, total, page, perPage }. Ohne den Parameter antwortet der Endpunkt noch in der bisherigen Form (ein blankes Array derselben Einträge); sie ist veraltet, ab dem 18.01.2027 ist { items, ... } der Standard.

ID-JAG-AgentenAnkerlink kopieren

Agenten, die du über einen Identity-Provider freigegeben hast (siehe Identity Assertion (ID-JAG)), stehen nach den OAuth-Verbindungen, ein Eintrag je freigegebenem Agenten: client_id ist die Registrierungskennung (reg_…), client_name ist "<Provider-Host> (Agent)", connected_at der Zeitpunkt der Freigabe, last_active das zuletzt für ihn ausgestellte Token (oder die Freigabe, falls es noch keins gibt), und scope ist "read-write", wenn du mindestens einen Schreibbereich freigegeben hast, sonst "read-only".

Eine Verbindung widerrufenAnkerlink kopieren

DELETE /api/oauth/connections/:clientId

Widerruft deine eigene Berechtigung für den angegebenen Client: löscht sofort dessen Access-/Refresh-Token und den Consent-Eintrag. Die App verliert den Zugriff sofort; für eine erneute Verbindung muss der Nutzer den OAuth-Zustimmungsprozess erneut durchlaufen.

Beginnt die client_id mit reg_ (ein ID-JAG-Agent), wird die Registrierung des Agenten widerrufen, zusammen mit jedem daraus abgeleiteten Zugriffstoken. Das darf nur die Person, die den Agenten freigegeben hat; alle anderen bekommen 404 unknownOauthConnection. Um wieder Zugriff zu bekommen, muss der Agent erneut auf /claim freigegeben werden.

Beispiel (cURL)Ankerlink kopieren

curl -X DELETE "$BASE_URL/api/oauth/connections/claude-desktop" \
  -H "Cookie: $SESSION_COOKIE"

AntwortAnkerlink kopieren

{ "revoked": true, "client_id": "claude-desktop" }

Häufige FehlerAnkerlink kopieren