Ein API-Schlüssel, der alles darf, ist ein Schlüssel, den man nicht weitergeben kann

Sie wählen die Berechtigungen beim Anlegen, aus demselben Katalog wie bei den Rollen. Ein Schlüssel, der Kontakte von Ihrer Website übermitteln soll, kann Ihre Rechnungen nicht lesen, und die Ablehnung kommt vom Gateway, nicht von einer Konvention im Code. Das ist das Modell der eingeschränkten Stripe-Schlüssel und der feingranularen GitHub-Token.

• Berechtigungen aus dem RBAC-Katalog gewählt
• Prüfung bei jedem Aufruf, am Gateway
• Geheimer oder öffentlicher Schlüssel, je nach Zweck
• Bezeichnung und Notiz, damit klar ist, wofür er dient

Ein Schlüssel kann ein Ablaufdatum tragen. Und auch ohne Datum gilt ein Inaktivitätsfenster von neunzig Tagen: Ein Schlüssel, den niemand mehr nutzt, hört von selbst auf zu funktionieren. Das ist das banalste Leck überhaupt — ein Schlüssel, der an einem Dienstag in ein Skript kam und drei Jahre lang vergessen wurde.

• Ausdrückliches Ablaufdatum, nach Wunsch
• Zusätzlich neunzig Tage Inaktivitätsfenster
• Datum der letzten Nutzung angezeigt
• Sofortiger Widerruf, mit dem Namen des Widerrufenden

Den Schlüssel im Klartext gibt es nur in dem Moment, in dem Sie ihn anlegen: danach wird nur seine Prüfsumme aufbewahrt, und nichts kann ihn zurücklesen — weder die Oberfläche noch der Support noch das Audit-Protokoll, das das Ereignis festhält, ohne je den Wert zu tragen. Geht er verloren, legt man einen neuen an und widerruft den alten.

• Wert einmal angezeigt, nie im Klartext gespeichert
• Audit-Protokoll ohne Geheimnis und ohne Prüfsumme
• E-Mail-Warnung bei einer nie gesehenen IP-Adresse
• Anlage und Widerruf ihrem Urheber zugeordnet