Senden Sie einfach einen Schlüssel im HTTP-Header, um sich für einen REST-Aufruf zu authentifizieren.

Question

Ich habe einige REST-Dienste auf meiner Website, auf die Dritte zugreifen können. Mein Plan ist einfach. Um diese Dienste in Anspruch zu nehmen, müssen sie einen Schlüssel von mir anfordern. Ich werde sie privat mit einer GUID versorgen. Jeder Anruf bei einem meiner Dienste überprüft über einen Filter die Kopfzeile des Schlüssels und akzeptiert/lehnt die Anfrage entsprechend ab. Diese Seite ist alles HTTPS, also würde der Schlüssel während des Transports verschlüsselt werden. Ich mache mir keine Sorgen, dass der Schlüssel für autorisierte Kunden visuell erkennbar ist. Mit anderen Worten, ich mache mir keine Sorgen über irgendwelche "Inside" -Angriffe oder Leute, die den Schlüssel teilen. Ich will einfach keine zufälligen, nicht autorisierten externen Benutzer.

Ich habe mich umgesehen und ich sehe wirklich niemanden, der es genau so macht. Ich fühle mich, als würde ich mich zu sehr vereinfachen ... aber auf der anderen Seite sehe ich auch nicht, was damit nicht stimmt.

Meine Frage ist ... klingt das sicher genug (aus einer grundlegenden/minimalen Perspektive) oder zeigt es einige klaffende Sicherheitslücke, die ich nicht sehe?

FWIW - ich bin mit dem Spring Framework verwenden, einschließlich Spring Security 4.

Dank!

Answer 1

Wenn es HTTPS ist und der API-Schlüssel in der Kopfzeile während des Transports verschlüsselt ist, wie Sie es beschrieben haben, dann folgt es einem ziemlich standardmäßigen Design-Authentifizierungsmuster.

Ihre Sicherheit hängt jetzt davon ab, wie Sie Ihre API-Schlüssel verteilen und speichern.

Obwohl, könnten Sie eine "Application Identifier and Key pairs" Ansatz verwenden.

Während des API-Key-Musters kombiniert die Identität der Anwendung und der geheimen Nutzung Token in einem Token, dieses Muster trennt die zwei. Jede Anwendung, die die API verwendet, gibt eine unveränderliche initiale Kennung aus, die als Anwendungs-ID (App ID) bekannt ist. Die App ID ist Konstante und kann oder darf nicht geheim sein. Zusätzlich kann jede Anwendung 1-n-Anwendungsschlüssel (App_Keys) haben. Jeder Schlüssel ist direkt mit der App_ID verbunden und sollte als geheim behandelt werden.

Nur für den Fall, dass Sie die Anwendung in der Zukunft erweitern möchten.