API-Key-Berechtigungen entscheiden, was ein geleakter Key kaputtmachen kann. In einem Link-Tool ist der sichere Standard ein Key, der an einen einzigen Workspace gebunden ist, auf die niedrigste Rolle begrenzt, die die Aufgabe erledigt, als Hash mit Pepper gespeichert, mit eigenem Rate Limit versehen und mit Ablaufdatum. Ein Key, der nur Links anlegt, hat nichts an Webhooks, Mitgliedern oder Abrechnung verloren und darf nie einen Admin-Endpunkt öffnen. Das ist Least Privilege, und das meiste davon entscheidet sich in den dreißig Sekunden, die das Erstellen des Keys dauert.
Ich habe im vergangenen Jahr viele Automatisierungs-Setups gelesen, und das Muster wiederholt sich: Jemand fügt an einem Freitagnachmittag seinen eigenen allmächtigen Key in n8n ein, es funktioniert, und niemand denkt mehr daran, bis diese Person geht oder der Workflow-Export in einem gemeinsamen Laufwerk landet. Der Rest dieses Beitrags erklärt, wie API-Key-Scopes und Rollen in einem Kurzlink-Produkt funktionieren, was jede Rolle tatsächlich darf und wie du einem Automatisierungs-Tool einen Key übergibst, ohne den Workspace mit zu übergeben.
Er ergänzt unsere umfassendere Sicherheits-Checkliste für URL-Shortener, die Scanning, Webhook-Signierung und Audit-Logs über die ganze Plattform behandelt. Dieser Beitrag nimmt den Key selbst unter die Lupe.
Was API-Key-Berechtigungen in einem Link-Tool bedeuten
Die API eines Link-Tools berührt mehr als Links. Dasselbe Token, das go.example.com/spring-sale anlegt, kann je nach Berechtigungen Klick-Analytics lesen, eine Custom Domain hinzufügen, ein Mitglied einladen oder einen Webhook registrieren, der jedes Event an einen externen Server schickt. Der letzte Punkt macht mir Angst. Ein Webhook ist ein dauerhafter Datenstrom, den wer ihn anlegt auf jeden beliebigen Server richten kann, und niemand in deinem Team würde es unbedingt wochenlang bemerken.
Berechtigungen haben also drei Achsen. Wo funktioniert der Key (welches Konto oder welcher Workspace)? Was kann er dort tun (lesen, schreiben, administrieren)? Und wie lange und wie schnell? Die Glossar-Definition des NIST für Least Privilege (abgerufen am 2026-10-24) sagt, jede Einheit erhält die minimalen Berechtigungen, die sie für ihre Funktion braucht, und alle drei Achsen gehören dazu. Ein Key mit reinen Leserechten, der nie abläuft und kein Rate Limit hat, ist zeitlich trotzdem überprivilegiert.
Workspace-gebundene API-Keys: Ein Key, ein Workspace
Bei Elido wird jeder Key innerhalb eines Workspace erzeugt und bleibt dort. Rufst du mit ihm Endpunkte eines anderen Workspace auf, bekommst du einen 404, dieselbe Antwort wie bei einem Workspace, den es nicht gibt, sodass ein Key nicht einmal bestätigen kann, dass andere Workspaces existieren.
Das ist wichtiger, als es klingt. Agenturen und größere Teams gehören oft fünf oder zehn Workspaces an. Würde ein persönlicher Key alles erben, was sein Ersteller erreicht, öffnete ein geleaktes Token aus einem Kundenprojekt alle Kunden. Workspace-gebundene API-Keys verkleinern den Schadensradius auf einen Workspace.
Der Key ist zudem auf die Rolle begrenzt, die beim Erstellen gewählt wurde, und übersteigt nie die aktuelle Rolle seines Erstellers. Der effektive Zugriff ist der niedrigere von beiden. Stufst du den Admin, der einen Key erstellt hat, auf Editor herab, fällt der Key mit ihm. Individuelle Berechtigungen, die diesem Mitglied zugeordnet sind, entfallen ebenfalls, sobald die Rolle des Keys die niedrigere ist, denn sie beschreiben die Person, nicht den Key.
Rollenbasierte API-Keys: Was jede Rolle darf
Elido-Keys nutzen dieselben vier Rollen wie Menschen: Viewer, Editor, Admin und Owner. Du wählst beim Erstellen eine; lässt du sie weg, ist der Key standardmäßig Editor, was die übliche Automatisierungsaufgabe abdeckt, Links anzulegen und Analytics zu lesen, ohne Admin-Reichweite.
So sieht das in der Praxis für die Dinge aus, die Integrationen üblicherweise berühren.
| Rolle | Links und Kampagnen | Analytics | Webhooks | Domains, Mitglieder, Keys |
|---|---|---|---|---|
| viewer | Nur lesen | Lesen, CSV-Export-Jobs starten | Endpunkte auflisten | Domains und Mitglieder ansehen |
| editor | Erstellen, bearbeiten, löschen, Bulk-Erstellung | Lesen, CSV-Export-Jobs starten | Endpunkte auflisten | Domains und Mitglieder ansehen |
| admin | Alles, was ein Editor darf | Zusätzlich S3-Datenexport-Konfiguration, geplante E-Mail-Reports | Erstellen, ändern, Replay | Domains, Mitglieder, Keys verwalten |
| owner | Alles | Alles | Alles | Alles |
Ein Reporting-Dashboard, das Klickzahlen in ein BI-Tool zieht, braucht Viewer. Ein Google-Sheets-Job, der Kampagnenlinks erzeugt, braucht Editor. Fast nichts in der täglichen Automatisierung braucht Admin, und einen Owner-Key würde ich als Warnsignal behandeln: Owner gibt es für die Menschen, die den Workspace betreiben, und mir fällt keine Automatisierungsaufgabe ein, die ihn bräuchte.
Zwei Grenzen sind wissenswert. Nur Admins und Owner halten die Berechtigung api_keys.manage, ein Viewer- oder Editor-Key kann also keine Keys auflisten oder widerrufen. Und das Erstellen eines Keys oder die Änderung seines Rate Limits braucht eine angemeldete Person: Ein API-Key jeder Rolle erhält einen 403 ("this action requires an interactive session"). Ein geleakter Admin-Key kann also keinen nicht ablaufenden Ersatz erzeugen. Er kann aber weiterhin Keys auflisten und widerrufen. Und kein Key irgendeiner Rolle erreicht die Plattform-Admin-API. Diese Oberfläche lehnt API-Key-Authentifizierung komplett mit einem 403 und der Meldung "admin access requires an interactive session" ab. Ein Key ist für eine Workspace-Integration da, und mehr öffnet er nicht.
Warum die Webhook-Verwaltung einen Admin-Key braucht
Das überrascht die Leute. Die Liste der Webhook-Endpunkte zu lesen ist jedem Mitglied erlaubt, auch Viewer-Keys. Aber einen Endpunkt zu erstellen, sein Ziel zu ändern oder eine Zustellung erneut einzuspielen (Replay) erfordert die Berechtigung workspace.edit, die nur Admin und Owner haben.
Der Grund ist das Problem des dauerhaften Datenstroms von vorhin. Wenn ein Editor tausend Links anlegt, merkst du es. Könnte ein Editor einen Catch-all-Webhook auf seinen eigenen Server setzen, bekäme er von da an still jedes Link-Event. Deshalb liegen Webhook-Änderungen bei denselben Leuten, die Workspace-Einstellungen ändern dürfen.
In der Praxis richtest du Webhooks einmal von Hand als Admin im Dashboard ein. Danach gibst du der Automatisierung, die sie nutzt, für ihre API-Aufrufe einen Editor- oder Viewer-Key. Wenn du Webhooks für Link-Events in Slack oder ein CRM einbindest, braucht die empfangende Seite gar keinen Elido-Key; sie braucht das Signing-Secret, um Payloads zu verifizieren.
Willst du einen Beweis, bevor du etwas verdrahtest? Erstelle einen kostenlosen Workspace, erzeuge einen Viewer- und einen Editor-Key und probiere mit beiden denselben schreibenden Aufruf. Der 403 beim Viewer-Key sagt dir mehr als jede Tabelle.
Wie Keys gespeichert werden: Pepper, Hash und Präfix
Ein Token sieht aus wie elido_ gefolgt von 52 Zeichen Base32, erzeugt aus 32 Zufallsbytes. Du siehst es genau einmal, in der Antwort auf den Create-Aufruf. Danach ist es auf unserer Seite endgültig weg.
Wir behalten einen HMAC-SHA256 des Tokens, mit einem serverseitigen Pepper als Schlüssel, der in der Konfiguration der Anwendung liegt, nicht in der Datenbank. Bei jedem Request wird das eingehende Bearer-Token (das Schema ist in RFC 6750 definiert, abgerufen am 2026-10-24) auf dieselbe Weise gehasht und per Hash nachgeschlagen. Ein gestohlener Datenbank-Dump ist also eine Liste von Hashes, die niemand ohne den Pepper prüfen kann. Kein Pepper, kein Start: Der Produktionsdienst startet nicht ohne gesetzten Pepper.
Für deine eigenen Unterlagen speichern wir die ersten acht Zeichen nach elido_ als Anzeige-Präfix, und die Seite mit den API-Keys zeigt dieses Präfix neben Name, Rolle, Erstellungsdatum, Ablauf, Zeitpunkt der letzten Nutzung und IP der letzten Nutzung des Keys, dazu die Gesamtzahl der Requests und der fehlgeschlagenen. Taucht ein Key irgendwo in einem Log auf, sagt dir das Präfix, welcher es ist. Niemand muss das vollständige Secret sehen.
Rate Limits, Ablauf und API-Key-Rotation
Jeder Key bekommt seinen eigenen Token Bucket, getrennt vom Limit pro Workspace, sodass ein außer Kontrolle geratener Workflow nicht das Budget für alles andere auffrisst. Ein angemeldeter Admin kann die Rate eines einzelnen Keys auf 1 bis 10.000 Requests pro Sekunde und den Burst auf 1 bis 20.000 setzen oder die Überschreibung löschen, um auf den Standard zurückzufallen. Über dem Limit erhält der Key einen 429 mit Retry-After: 1 und X-RateLimit-Scope: api_key, damit deine Retry-Logik ein Key-Limit von einem Workspace-Limit unterscheiden kann. Der Leitfaden zu Rate Limits und Idempotenz behandelt sauberes Backoff.
Ein Ablauf ist optional und wird beim Erstellen als RFC-3339-Zeitstempel gesetzt. Sobald er verstrichen ist, passt der Key schlicht nicht mehr. Der Widerruf ist ein einziges DELETE. Es ist außerdem idempotent.
Es gibt keinen einzelnen Button "Rotieren", und er fehlt mir nicht. Die Rotation besteht aus drei Schritten:
- Einen neuen Key mit derselben Rolle und einem frischen Ablaufdatum erstellen.
- Ihn im Credential-Store des Tools austauschen und bestätigen, dass ein Aufruf gelingt.
- Den alten Key widerrufen und in der Liste prüfen, dass sich sein Zeitpunkt der letzten Nutzung nicht mehr bewegt.
Jeder Schritt landet im Audit-Log des Workspace: api_key.created mit Name und Rolle, api_key.revoked und api_key.rate_limit_set für Überschreibungen. Zusätzlich läuft alle fünf Minuten ein Hintergrund-Scan und markiert jeden Key mit mehr als 1.000 Requests, von denen über 30 % fehlschlugen. Die Markierung geht ins Audit-Log und an den Key. Kein automatischer Widerruf. Einen Key abzuschalten ist eine menschliche Entscheidung, denn ein Schwall von 404 ist ebenso oft ein kaputter Workflow wie ein Angreifer.
Least-Privilege-API-Keys an n8n, Make und Zapier übergeben
Automatisierungsplattformen sind der Ort, an dem Keys vergessen werden. Sie liegen in einem Credential-Store, werden in exportiertes Workflow-JSON kopiert und überdauern die Person, die sie eingerichtet hat. Zwei Gewohnheiten helfen:
- Ein Key pro Tool und pro Workflow-Familie, danach benannt ("n8n: campaign sheets"). Sein Widerruf bricht dann genau eine Sache, und das Audit-Log sagt, welches Tool was getan hat.
- Editor für alles, was Links anlegt, Viewer für alles, was nur liest, und bei beiden ein Ablaufdatum.
Das ist die ganze Liste; der Rest ist Urteilsvermögen. Das Secrets Management Cheat Sheet von OWASP (abgerufen am 2026-10-24) ist eine gute Lektüre dazu, Tokens aus Logs und Exporten herauszuhalten, wo Automatisierungs-Keys meist leaken.
Für die toolspezifische Einrichtung legt der Leitfaden zum n8n-URL-Shortener den Key in eine Header-Auth-Credential, und der Vergleich Make vs IFTTT vs n8n vs Zapier zeigt, wo jede Plattform ihn ablegt. Zapier verbindet sich laut Zapier-Automatisierungs-Anleitung über dasselbe Token. Für CI oder alles, was das Ausscheiden einer Person überleben soll, passt ein Machine User besser: ein Service-Account mit eigenem Token, getrennt vom Key eines Menschen. Wie Keys werden Machine User von einem angemeldeten Admin angelegt, nie von einem Token.
Und der Grund, warum ein Key nie Admin-Endpunkte öffnen darf, ist genau diese Übergabe. Sobald ein Token in einem Drittanbieter-Tool liegt, kann jeder mit Bearbeitungsrechten an den Workflows dieses Tools es nutzen. Du vertraust allen auf deren Seite, nicht nur auf deiner.
Tokens pro Scope sind geplant, nicht live
Rollen sind absichtlich grob, manchmal zu grob. Ein Editor-Key, der nur Links anlegt, kann sie auch löschen, weil das Löschen Teil der Rolle Editor ist. Die Lösung sind Tokens pro Scope, etwa links:write oder analytics:read, direkt an einen Key gebunden und über den Rollen geschichtet.
Das steht auf unserer Roadmap und ist nicht ausgeliefert. Heute sind die Berechtigungen eines Keys sein Workspace plus seine Rolle, nichts Feineres. Brauchst du jetzt engere Kontrolle, sind die zwei Hebel eine niedrigere Rolle und ein kurzer Ablauf, dazu getrennte Keys pro Aufgabe, damit der Schadensradius jedes einzelnen klein bleibt. Die API-Schnellstart-Anleitung und die API- und SDK-Referenz zeigen das aktuelle Key-Modell in funktionierendem Code, und Teams, die zusätzlich Kontrolle auf Identitätsebene wollen, können über SCIM und SSO für Marketing-Tools nachlesen.
Lies den Cornerstone-Beitrag: Die Sicherheits-Checkliste für URL-Shortener behandelt die Kontrollen rund um den Key, vom URL-Scanning bis zu IP-Allowlists.
Weitere Beiträge im Blog
Häufig gestellte Fragen
Was sind API-Key-Berechtigungen?
Sie sind die Menge der Aktionen, die ein Key gegenüber einer API ausführen darf: welche Ressourcen er lesen, welche er ändern kann und in welchem Konto. Bei Elido ergeben sich die Berechtigungen eines Keys aus dem Workspace, in dem er ausgestellt wurde, und der Rolle, die beim Erstellen gewählt wurde. Derselbe Key kann also weder in einem anderen Workspace noch oberhalb dieser Rolle handeln.
Was bedeutet Least Privilege bei API-Keys?
Jeder Key bekommt die kleinste Menge an Berechtigungen, die seine Aufgabe braucht, und nicht mehr. Ein Dashboard, das nur Klickzahlen liest, bekommt einen Viewer-Key, ein Workflow, der Links anlegt, einen Editor-Key, und Admin-Keys bleiben für die seltene Aufgabe reserviert, die Webhooks, Domains oder Mitglieder verwaltet. Ein geleakter Key kann dann nur tun, was diese eine Aufgabe tat.
Was ist der Unterschied zwischen API-Key-Scopes und Rollen?
Ein Scope ist eine enge Berechtigung wie links:write, die direkt an ein Token gebunden ist, eine Rolle dagegen ein benanntes Bündel von Berechtigungen wie Editor. Rollen sind leichter zu überblicken; Scopes sind feiner. Elido-Keys nutzen heute Workspace-Rollen, und Tokens pro Scope sind darauf aufbauend geplant, aber noch nicht live.
Wie oft sollten API-Keys rotiert werden?
Üblich sind alle 30 bis 90 Tage, plus sofort, wenn jemand geht, der den Key gesehen hat, der Key in einem Log auftaucht oder sein Traffic auffällig aussieht. Ein beim Erstellen gesetztes Ablaufdatum macht aus diesem Rhythmus einen harten Stopp statt einer Kalender-Erinnerung, die Leute ignorieren.
Kann ein API-Key auf Admin-Endpunkte zugreifen?
Bei Elido nein. Die Plattform-Admin-API akzeptiert nur eine interaktive, angemeldete Sitzung und beantwortet einen API-Key mit 403, unabhängig von der Rolle der Person, die ihn erstellt hat. Workspace-Einstellungen, die Admin-Rechte brauchen, sind weiterhin erreichbar, aber nur mit einem Key, der mit der Rolle Admin oder Owner erstellt wurde.
Wie sollte der Anbieter API-Keys speichern?
Niemals im Klartext. Der Anbieter sollte einen Hash des Tokens mit Schlüssel speichern und dir danach nur ein kurzes Präfix zeigen, sodass eine Kopie der Datenbank allein nicht reicht, um die API aufzurufen. Elido hasht jedes Token mit HMAC-SHA256 und einem serverseitigen Pepper und zeigt das vollständige Token genau einmal.
Elido testen
URL einfügen, kurzer Link in Sekunden
Kein Konto nötig. Link bleibt 30 Tage aktiv. Konto erstellen, um ihn dauerhaft zu behalten.
Keine Anmeldung nötig. Kostenlos registrieren für 50 Links im Monat.