API-Schlüssel

Erstelle und verwalte Zugriffstoken für die API.

Ein Schlüssel lässt ein Skript, einen Dienst oder eine Integration in deinem Arbeitsbereich handeln, ohne Browser-Sitzung. Die API selbst ist auf docs.steerd.io dokumentiert.

Einen erstellen

Gib dem Schlüssel einen Namen, wähle die Zugriffsstufe und optional ein Ablaufdatum.

Benenne ihn nach dem, was ihn benutzt, nicht nach dir. "CI Deploy Token" sagt dir, was kaputt geht, wenn du ihn widerrufst. "Annas Schlüssel" sagt das nicht.

Berechtigungen

Der Zugriff wird pro Ressource festgelegt: Organisationen, Kontakte, Mitarbeiter, Projekte und so weiter. Für jede wählst du keine, Lesen oder Schreiben.

Schreiben schließt Lesen ein.

Gib das Minimum, das funktioniert. Ein Schlüssel, der nur Projekte liest, richtet auch dann keinen Schaden an, wenn er nach außen gerät, und die meisten Integrationen lesen tatsächlich nur.

Mindestens eine Berechtigung ist Pflicht, denn ein Schlüssel, der nichts erreicht, ist keiner.

Ablauf

Optional und empfehlenswert. Ein Schlüssel mit Ablaufdatum scheitert an einem bekannten Tag laut und deutlich. Einer ohne lebt, bis sich jemand an ihn erinnert, in der Praxis also für immer.

Kopier ihn jetzt

Der Schlüssel wird einmal angezeigt, beim Erstellen. Steerd speichert einen Hash und nicht den Schlüssel, kann ihn dir also nicht noch einmal zeigen, und der Support kann es auch nicht. Weg ist weg, dann erstellst du einen neuen.

Widerrufen

Sofort wirksam. Alles, was diesen Schlüssel nutzt, hört augenblicklich auf zu funktionieren. Genau das willst du, wenn ein Schlüssel nach außen geraten ist, und es ist lästig, wenn du den falschen widerrufen hast. Das ist das Argument für gute Namen.

Erstellen und Widerrufen landen im Audit-Log.

Wenn ein Mitglied entfernt oder deaktiviert wird

Entfernst oder deaktivierst du ein Mitglied, werden mit der Bestätigung alle Schlüssel gesperrt, die diese Person in diesem Team angelegt hat. Für ihre Sync-Passwörter gilt dasselbe. Mehr dazu unter Kontakte aufs Handy synchronisieren.

Die Sperre ist endgültig. Lädst du die Person wieder ein oder aktivierst sie erneut, bekommt sie ihre Mitgliedschaft zurück. Die Schlüssel bleiben gesperrt, denn ein Schlüssel, der gültig war, solange jemand Zugriff hatte, darf nicht von allein wieder gültig werden.

Zwei Punkte, über die dabei die meisten stolpern:

• Wer zurückkommt, braucht einen neuen Schlüssel von einem Admin. Jedes Skript und jeder Dienst mit dem alten Schlüssel muss angepasst werden. Umgestellt wird nichts von allein, also scheitert die Integration so lange weiter, bis jemand sie anfasst.
• Auch verbundene Apps hängen an einem Schlüssel. Autorisiert jemand eine App über OAuth, wird dafür ein Schlüssel für diese Person angelegt. Entfernst du diese Person, verliert die App den Zugriff, auch wenn dieses Mitglied nie von Hand einen Schlüssel angelegt hat. Dann hilft nur, die App neu zu autorisieren.

Schlüssel von allen, die im Team bleiben, sind nicht betroffen. Was gesperrt wurde und warum, steht im Audit-Log. Dort siehst du am schnellsten, welche Integration ausgefallen ist.

Mehr zum Entfernen selbst: Team, Rollen und Plätze.