Der Client sendet ihn an einer definierten Stelle der Anfrage, üblicherweise in einem HTTP-Header. Je nach Design kann der Schlüssel als geteiltes Geheimnis, als öffentlicher Identifikator oder als beides wirken.
API-Schlüssel sind häufig langlebig und identifizieren üblicherweise nicht den einzelnen Benutzer hinter einer Anfrage. Sicherer Betrieb erfordert einen Eigentümer, einen definierten Zweck, die engsten praktikablen Berechtigungen und Umgebung, geschützte Übermittlung und Speicherung, Nutzungsmonitoring, Rotation und prompten Widerruf. Schlüssel sollten nicht in öffentlichen Client-Code eingebettet oder in URLs platziert werden, wo Logs und Vermittler sie aufzeichnen können.
Wichtigste Punkte
PrimärrolleEiner API ermöglichen, einen aufrufenden Client, Workload, ein Projekt oder Abonnement zu erkennen und Richtlinie anzuwenden.
AutorisierungsgrenzeBerechtigungen an jedem Endpunkt durchsetzen; der Besitz eines Schlüssels sollte objekt- oder funktionsebene Autorisierung nicht umgehen.
Betriebliche KontrollenGetrennte Schlüssel je Nutzer und Umgebung ausgeben, ihre Verwendungsorte einschränken, abnormes Volumen überwachen und einen getesteten Austauschprozess pflegen.
Wichtige EinschränkungEin API-Schlüssel ist oft ein wiederholbares Bearer-Geheimnis und kann bei geteilter Nutzung schwache Zuschreibung liefern. Er ist nicht automatisch Benutzerauthentifizierung, delegierte Autorisierung, Verschlüsselung oder ein Beweis, dass eine Anfrage legitim ist.