it-swarm.com.de

Speicherort eines API-Schlüssels: Ein benutzerdefinierter HTTP-Header im Vergleich zum Autorisierungsheader mit einem benutzerdefinierten Schema

Ich entwerfe eine REST API mit Autorisierung/Authentifizierung über einen API-Schlüssel.

Ich habe versucht herauszufinden, wo es am besten ist, und festgestellt, dass viele Leute die Verwendung eines benutzerdefinierten HTTP-Headers wie ProjectName-Api-Key Vorschlagen, z.

ProjectName-Api-Key: abcde

es ist aber auch möglich und ideologisch korrekt, den Header Authorization mit einem benutzerdefinierten Schema zu verwenden, z.

Authorization: ApiKey abcde

Andererseits habe ich festgestellt, dass ein benutzerdefiniertes Autorisierungsschema von einigen Clients unerwartet und nicht unterstützt werden kann und trotzdem zu benutzerdefiniertem Code führt. Daher ist es besser, einen benutzerdefinierten Header zu verwenden, da Clients keine Erwartungen daran haben.

Auf welche Weise möchten Sie einen API-Schlüssel senden?

25
RomanG

Seien Sie konsequent

Einige mögen sagen, dass dies unnötig ist ( und vor nicht allzu langer Zeit hätte ich zugestimmt ), aber heutzutage mit so vielen Authentifizierungsprotokollen, wenn wir die Authorization -Header zum Übergeben eines API-Schlüssels , der es wert ist, auch über den Typ informiert zu werden, da API-Schlüssel per se nicht selbstbeschreibend sind 1.

Warum denke ich, dass es sich lohnt? Weil heutzutage die Unterstützung unterschiedlicher Authentifizierungs- oder/und Autorisierungsprotokolle zu einem Muss geworden ist. Wenn wir den Header Authorization für alle diese Protokolle verwenden möchten, müssen wir unseren Authentifizierungsdienst konsistent machen. Die Art und Weise, wie Sie kommunizieren, welche Art von Token wir senden und welches Autorisierungsprotokoll angewendet werden soll, sollte ebenfalls im Header enthalten sein.

Authorization: Basic XXXX
Authorization: Digest XXXX
Authorization: Bearer XXXX
Authorization: ApiKey-v1 XXXX
Authorization: ApiKey-v2 XXXX

Früher war mir das egal, aber nachdem ich mit mobilen Clients oder Sensoren gearbeitet hatte, deren Aktualisierungen nicht garantiert waren, begann ich damit. Ich begann, die Art und Weise, wie ich Sicherheit implementiere, konsistenter zu gestalten, damit ich die Abwärtskompatibilität beibehalten kann. Wenn der Typ des Tokens informiert ist, kann ich Anforderungen von einer bestimmten Gruppe von Clients (die veralteten) ungültig machen, neue Schemata hinzufügen und alte Clients von neuen unterscheiden, Authentifizierungsvalidierungen für das eine oder andere Schema ändern, ohne Änderungen zu verursachen. Ich kann auch bestimmte Regeln in den API-Gateways anwenden, die auf dem informierten Autorisierungsschema basieren. Beispielsweise kann ich alte Schemata auf bestimmte Versionen meiner Web-APIs umleiten, die neben den Hauptversionen bereitgestellt werden.

Sorgen

Die Probleme, mit denen ich bei der Umsetzung meiner eigenen Systeme konfrontiert war, waren ähnlich wie die kommentierten.

Andererseits habe ich festgestellt, dass ein benutzerdefiniertes Autorisierungsschema von einigen Clients unerwartet und nicht unterstützt werden kann und trotzdem zu benutzerdefiniertem Code führt

Sagen Sie Clients , sagen Sie Bibliotheken, Frameworks, Reverse Proxies . Ein benutzerdefinierter Header kann abgelehnt oder ignoriert werden. Im schlimmsten Fall kann es auch kollidieren.

Vorteile

Ein wichtiger Vorteil ist der Cache. Freigegebene Caches werden den Header nicht zwischenspeichern (und das ist natürlich gut), sofern Sie nichts anderes sagen.

Also Autorisierung oder benutzerdefinierter Header?

Meiner Erfahrung nach benötigen beide fast die gleiche Arbeit und Zeit für die Implementierung, mit einem kleinen Unterschied, dass ich mehr Platz für Design habe, wenn ich benutzerdefinierte Header implementiert habe. Mehr Raum für Design bedeutete jedoch auch mehr Chancen, Dinge zu komplizieren.

Technisch gesehen könnte es kaum oder gar keinen Unterschied zwischen den beiden geben, aber ich habe festgestellt, dass die Konsistenz eine Eigenschaft jeder Lösung ist, die ich für das, was sie mir bietet, Klarheit und Verständnis schätze. In meinem Fall wurde das Hinzufügen neuer Schemata reduziert, um zwei neue Abstraktionen hinzuzufügen (implementiert von derselben konkreten Klasse): TokenHandler und TokenValidator . Der Handler prüft nur, ob die Autorisierung des Anforderungsheaders das unterstützte Schema informiert. Der Validator ist alles, was ich brauche, um das Token zu validieren. Insgesamt wird mit einem einzigen Anforderungsfilter gearbeitet, anstatt mit einer Filterkette oder einem großen Schlammballen.


1: Ich finde, dass diese Antwort in Bezug auf API-Schlüssel sehr klar ist

16
Laiv