Das Problem mit API-Schlüsseln, die nie ablaufen
Ein Schlüssel, der vor Jahren ausgestellt, nie rotiert wurde und heute noch gültig ist, ist keine Bequemlichkeit. Er ist ein Risiko, das sich seit Jahren niemand mehr angesehen hat.
Warum grundlegende Authentifizierungsmethoden keinen Aufpreis kosten sollten
Authentifizierung gehört zu den eher banalen Teilen der Nutzung einer API, und genau solche banalen Details landen öfter hinter einer Preisstufe, als sie sollten. Manche Anbieter reservieren bestimmte Authentifizierungsmethoden, etwa HTTP Basic Auth oder ein Bearer-Token-Muster, für höher bezahlte Stufen, während eine niedrigere Stufe nur ein einziges, bestimmtes Header-Format unterstützt. Der technische Kostenunterschied zwischen der Prüfung des einen und des anderen Authentifizierungsstils ist nahezu null. Was sich unterscheidet, ist, wie bequem jede Methode für den bestehenden Code eines Kunden ist, und das hat nichts damit zu tun, wie viel er überhaupt für die Nutzung der API zahlen sollte.
Wir akzeptieren einen Schlüssel als X-API-Key-Header, als Authorization-Bearer-Header, über HTTP Basic Auth mit dem Schlüssel als Benutzername oder als Query-Parameter, auf jedem Host und ohne Aufpreis für irgendeine dieser Methoden. Welches Muster auch immer bereits zu Ihrem bestehenden Code passt, welche Bibliothek oder interne Konvention Ihr Team auch für andere APIs verwendet, sie wird sehr wahrscheinlich bereits unterstützt, ohne dass Sie etwas umbauen müssen, nur um ein bestimmtes Format zu treffen, das wir zufällig bevorzugen.
Hinter der Staffelung von Authentifizierungsmethoden nach Preisstufen stecken eigentlich keine Kosten. Es geht um Differenzierung der Stufen um ihrer selbst willen: Funktionen zu finden, die man zahlungskräftigeren Kunden vorbehalten kann, selbst Funktionen, deren Bereitstellung nichts extra kostet, einfach weil mehr gesperrte Funktionen die höhere Stufe in einer Vergleichstabelle wertvoller aussehen lassen. Authentifizierungsmethoden sind dafür ein leichtes Ziel, denn mehrere davon zu unterstützen ist für den Anbieter wirklich wenig Aufwand und für den Kunden wirklich bequem. Das macht die Sperre zu einer reinen Monetarisierungsentscheidung statt zu einer, die auf einem echten Kostenunterschied beruht.
Wir finden, dass eine solche Sperre Entwickler stillschweigend für eine Entscheidung bestraft, die nichts damit zu tun hat, wie viel Nutzen sie aus den eigentlichen Daten ziehen. Ein Team, dessen bestehende Werkzeuge standardmäßig Bearer-Tokens verwenden, sollte nicht mehr zahlen als ein Team, dessen Werkzeuge standardmäßig einen eigenen Header nutzen, wenn beide Teams genau dieselbe Abfrage stellen und genau dieselbe Antwort erhalten. Der Wert des Produkts ist die Antwort. Die Authentifizierungsmethode ist Installationstechnik, und Installationstechnik sollte kein Preisschild tragen, das davon abhängt, welches Rohr zufällig in Ihre bestehende Wand passt.
Dahinter steht ein allgemeineres Prinzip, das über die Authentifizierung hinaus gilt: Funktionen, deren Angebot den Anbieter nichts extra kostet, sollten nicht zu künstlichen Stufengrenzen werden, nur weil das möglich ist. Eine Stufenstruktur, die auf echten Kostenunterschieden wie dem Anfragevolumen beruht, ist vertretbar. Eine Stufenstruktur, die mit günstigen Annehmlichkeiten für Besserzahlende aufgefüllt wird, existiert vor allem, damit die Preisseite differenzierter wirkt, als das zugrunde liegende Produkt tatsächlich ist.