API-Schlüssel vs HTTP-Authentifizierung vs OAuth in einer RESTful-API

Ich arbeite daran, eine RESTful-API für eine der von mir verwalteten Anwendungen zu erstellen. Wir versuchen derzeit, verschiedene Dinge einzubauen, die einen kontrollierten Zugang und mehr Sicherheit erfordern. Während ich nachforschte, wie die API gesichert werden kann, fand ich einige unterschiedliche Meinungen darüber, welche Form verwendet werden soll. Ich habe einige Ressourcen gesehen, die besagen, dass HTTP-Auth der richtige Weg ist, während andere API-Schlüssel bevorzugen, und sogar andere (einschließlich der Fragen, die ich hier auf SO gefunden habe) schwören auf OAuth.

Dann sagen natürlich diejenigen, die beispielsweise API-Schlüssel bevorzugen, dass OAuth für Anwendungen konzipiert ist, die im Namen eines Benutzers Zugriff erhalten (so wie ich es verstehe, z. B. die Anmeldung bei einer Nicht-Facebook-Site mit Ihrem Facebook-Konto). und nicht für einen Benutzer, der direkt auf Ressourcen auf einer Website zugreift, für die er sich speziell angemeldet hat (z. B. den offiziellen Twitter-Client, der auf die Twitter-Server zugreift). Die Empfehlungen für OAuth scheinen jedoch selbst für die grundlegendsten Authentifizierungsanforderungen zu gelten.

Meine Frage lautet also: Unter der Annahme, dass alles über HTTPS erfolgt, was sind einige der praktischen Unterschiede zwischen den drei? Wann sollte man über die anderen nachdenken?

Es hängt von Ihren Bedürfnissen ab. Brauchst du:

• Identität - wer behauptet, eine API-Anfrage zu stellen?
• Authentifizierung - sind sie wirklich so, wie sie sagen, dass sie sind?
• Autorisierung - dürfen sie das tun, was sie versuchen?

oder alle drei?

Wenn Sie nur den Anrufer identifizieren müssen, um das Volumen oder die Anzahl der API-Aufrufe zu verfolgen, verwenden Sie einen einfachen API-Schlüssel. Beachten Sie, dass der Benutzer, den Sie den API-Schlüssel ausgestellt haben, ihn auch mit einer anderen Person teilen kann, die auch Ihre API aufrufen kann.

Wenn Sie jedoch auch eine Autorisierung benötigen, dh nur Zugriff auf bestimmte Ressourcen basierend auf dem Aufrufer der API gewähren müssen, verwenden Sie oAuth.

Hier ist eine gute Beschreibung: http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/

API-Schlüssel oder sogar Tokens fallen in die Kategorie der direkten Authentifizierungs- und Autorisierungsmechanismen, da sie Zugriff auf exponierte Ressourcen der REST-APIs gewähren. Solche direkten Mechanismen können in Delegationsanwendungsfällen verwendet werden.

Um Zugriff auf eine Ressource oder eine Reihe von Ressourcen zu erhalten, die von REST-Endpunkten verfügbar gemacht werden, müssen die Anfordererberechtigungen anhand ihrer Identität überprüft werden. Der erste Schritt des Workflows besteht darin, die Identität durch Authentifizierung der Anforderung zu überprüfen . Der nachfolgende Schritt besteht darin, die Identität anhand eines Satzes definierter Regeln zu überprüfen, um die Zugriffsebene zu autorisieren (dh Lesen, Schreiben oder Lesen / Schreiben). Sobald die genannten Schritte ausgeführt sind, ist die zulässige Anforderungsrate ein typisches weiteres Problem , dh wie viele Anforderungen pro Sekunde der Anforderer für die angegebene (n) Ressource (n) ausführen darf.

OAuth (Open Authorization) ist ein Standardprotokoll für den delegierten Zugriff , das häufig von großen Internetunternehmen verwendet wird, um den Zugriff ohne Angabe des Kennworts zu gewähren. OAuth ist ein Protokoll, das die oben genannten Anforderungen erfüllt: Authentifizierung und Autorisierung durch Bereitstellung eines sicheren delegierten Zugriffs auf Serverressourcen im Namen des Ressourcenbesitzers. Es basiert auf dem Zugriffstoken-Mechanismus, der es dem Drittanbieter ermöglicht, im Auftrag des Ressourcenbesitzers auf die vom Server verwaltete Ressource zuzugreifen. Beispielsweise möchte ServiceX im Auftrag von John auf das Google-Konto von John Smith zugreifen, sobald John die Delegierung autorisiert hat. ServiceX erhält dann ein zeitbasiertes Token für den Zugriff auf die Google-Kontodaten, sehr wahrscheinlich nur beim Lesezugriff.

Das Konzept des API-Schlüssels ist dem oben beschriebenen OAuth-Token sehr ähnlich. Der Hauptunterschied besteht in der Abwesenheit einer Delegierung: Der Benutzer fordert den Schlüssel direkt beim Dienstanbieter für aufeinanderfolgende programmatische Interaktionen an. Der Fall des API-Schlüssels ist ebenfalls zeitbasiert: Der Schlüssel als OAuth-Token unterliegt einer Zeitmiete oder einer Ablauffrist. Als zusätzlicher Aspekt können sowohl der Schlüssel als auch das Token einer Ratenbegrenzung durch einen Servicevertrag unterliegen, dh es kann nur eine bestimmte Anzahl von Anforderungen pro Sekunde bedient werden.

Zusammenfassend lässt sich sagen, dass es in der Realität keinen wirklichen Unterschied zwischen herkömmlichen Authentifizierungs- und Autorisierungsmechanismen und schlüssel- / tokenbasierten Versionen gibt. Das Paradigma ist jedoch etwas anders: Anstatt bei jeder Interaktion zwischen Client und Server die Anmeldeinformationen wiederzuverwenden, wird ein Support-Schlüssel / Token verwendet, der das gesamte Interaktionserlebnis reibungsloser und wahrscheinlich sicherer macht (häufig gemäß dem JWT- Standard, Keys und Token werden vom Server digital signiert, um ein Basteln zu vermeiden.

• Direkte Authentifizierung und Autorisierung : Schlüsselbasierte Protokolle als Variante der herkömmlichen Versionen mit Anmeldeinformationen.
• Delegierte Authentifizierung und Autorisierung : Wie OAuth-basierte Protokolle, die wiederum Tokens verwenden, wiederum als Variante von Versionen mit Anmeldeinformationen (übergeordnetes Ziel besteht darin, das Kennwort nicht an Dritte weiterzugeben).

Beide Kategorien verwenden einen traditionellen Workflow zur Identitätsprüfung für die allererste Interaktion mit dem Server, der die interessierte (n) Ressource (n) besitzt.