it-swarm.com.de

Authentifizierung, Autorisierung und Sitzungsverwaltung in herkömmlichen Web-Apps und APIs

Korrigieren Sie mich, wenn ich falsch liege: In einer herkömmlichen Webanwendung hängt der Browser automatisch Sitzungsinformationen an eine Anfrage an den Server an, damit der Server weiß, von wem die Anfrage stammt. Was genau ist eigentlich angehängt?

In einer API-basierten App werden diese Informationen jedoch nicht automatisch gesendet. Wenn ich also eine API entwickle, muss ich selbst prüfen, ob die Anforderung beispielsweise von einem authentifizierten Benutzer stammt. Wie wird das normalerweise gemacht?

73
Jiew Meng

Das HTTP-Protokoll hat keinen Status, jede Anforderung wird separat ausgeführt und in einem separaten Kontext ausgeführt.

Die Idee hinter der Sitzungsverwaltung besteht darin, Anforderungen von demselben Client in denselben Kontext zu stellen. Dazu wird vom Server eine Kennung ausgegeben und an den Client gesendet. Anschließend speichert der Client diese Kennung und sendet sie bei nachfolgenden Anforderungen erneut, damit der Server sie identifizieren kann.

Kekse

In einem typischen Browser-Server-Fall; Der Browser verwaltet für jede Domain eine Liste von Schlüssel/Wert-Paaren, sogenannte Cookies:

  • Cookies können vom Server verwaltet werden (erstellt/geändert/gelöscht) mit dem Set-Cookie HTTP-Antwortheader.
  • Auf Cookies kann der Server zugreifen (lesen), indem er den HTTP-Anforderungsheader Cookie analysiert.

Web-bezogene Programmiersprachen/Frameworks bieten Funktionen für den Umgang mit Cookies auf einer höheren Ebene, z. B. PHP bietet setcookie / $_COOKIE um Cookies zu schreiben/lesen.

Sitzungen

Zurück zu Sitzungen In einem typischen Browser-Server-Fall nutzt die serverseitige Sitzungsverwaltung die clientseitige Cookie-Verwaltung. PHP's Session Management setzt ein Session ID Cookie und identifiziert damit nachfolgende Anfragen.

API für Webanwendungen?

Nun zurück zu Ihrer Frage. Da Sie für das Entwerfen und Dokumentieren der API verantwortlich sind, ist die Implementierung Ihre Entscheidung. Sie müssen im Grunde

  1. geben Sie dem Kunden eine Kennung, sei es durch ein Set-Cookie HTTP-Antwortheader im Antworttext (XML/JSON-Authentifizierungsantwort).
  2. über einen Mechanismus zur Aufrechterhaltung der Zuordnung von Bezeichner und Client verfügen. Zum Beispiel eine Datenbanktabelle, die den Bezeichner 00112233445566778899aabbccddeeff mit Client/Benutzer #1337.
  3. lassen Sie den Client die ID, die ihm bei (1.) in allen nachfolgenden Anforderungen gesendet wurde, erneut senden, sei es in einem HTTP-Anforderungsheader Cookie, einem ?sid=00112233445566778899aabbccddeeff param (*).
  4. suchen Sie die empfangene Kennung unter Verwendung des Mechanismus unter (2.), prüfen Sie, ob eine gültige Authentifizierung vorliegt, und sind Sie berechtigt, die angeforderte Operation auszuführen, und fahren Sie dann im Namen des autorisierten Benutzers mit der Operation fort.

Natürlich können Sie auf der vorhandenen Infrastruktur aufbauen, das Sitzungsmanagement von PHP (das sich um 1./2. Und den Authentifizierungsteil von 4. kümmert) in Ihrer App verwenden und die clientseitige Implementierung für das Cookie-Management (das) vorschreiben würde mich um 3.) kümmern, und dann machst du den Rest deiner App-Logik darauf auf.


(*) Jeder Ansatz hat Vor- und Nachteile. Die Verwendung eines GET-Anforderungsparameters ist einfacher zu implementieren, kann jedoch Auswirkungen auf die Sicherheit haben, da GET-Anforderungen protokolliert werden. Sie sollten https für alle kritischen Anwendungen verwenden.

120
aularon

Die Sitzungsverwaltung liegt in der Verantwortung des Servers. Wenn eine Sitzung erstellt wird, wird ein Sitzungstoken generiert und an den Client gesendet (und in einem Cookie gespeichert). Danach sendet der Client bei den nächsten Anforderungen zwischen Client und Server das Token (normalerweise) als HTTP-Cookie. Alle Sitzungsdaten werden auf dem Server gespeichert, der Client speichert nur das Token. Um zum Beispiel eine Sitzung in PHP zu starten, müssen Sie nur:

session_start();  // Will create a cookie named PHPSESSID with the session token

Nachdem die Sitzung erstellt wurde, können Sie Daten darauf speichern. Wenn Sie beispielsweise einen Benutzer angemeldet lassen möchten, gehen Sie wie folgt vor:

// If username and password match, you can just save the user id on the session
$_SESSION['userID'] = 123;

Jetzt können Sie überprüfen, ob ein Benutzer authentifiziert ist oder nicht:

if ($_SESSION['userID'])
    echo 'user is authenticated';
else
    echo 'user isn't authenticated';       

Wenn Sie möchten, können Sie eine Sitzung nur für einen authentifizierten Benutzer erstellen:

if (verifyAccountInformation($user,$pass)){ // Check user credentials
    // Will create a cookie named PHPSESSID with the session token
    session_start();
    $_SESSION['userID'] = 123;
}

Es gibt zahlreiche Möglichkeiten für authentische Benutzer, sowohl für Webanwendungen als auch für APIs. Es gibt einige Standards, oder Sie können Ihre eigene benutzerdefinierte Autorisierung und/oder Authentifizierung schreiben. Ich möchte auf den Unterschied zwischen Autorisierung und Authentifizierung hinweisen. Zunächst muss die Anwendung den Benutzer (oder API-Client) authentifizieren, von dem die Anforderung stammt. Nachdem der Benutzer authentifiziert wurde, muss die Anwendung basierend auf der Identität des Benutzers ermitteln, welcher authentifizierte Benutzer über die Berechtigung zum Ausführen einer bestimmten Anwendung verfügt (Autorisierung). Bei den meisten herkömmlichen Webanwendungen gibt es keine feine Granularität im Sicherheitsmodell. Sobald der Benutzer authentifiziert ist, ist er in den meisten Fällen auch berechtigt, bestimmte Aktionen auszuführen. Diese beiden Konzepte (Authentifizierung und Autorisierung) sollten jedoch zwei unterschiedliche logische Operationen sein.

Darüber hinaus werden in klassischen Webanwendungen nach der Authentifizierung und Autorisierung des Benutzers (meistens durch Nachschlagen des Benutzernamens/Kennworts in der Datenbank) die Autorisierungs- und Identitätsinformationen im Sitzungsspeicher gespeichert. Der Sitzungsspeicher muss nicht serverseitig sein, wie die meisten der obigen Antworten nahelegen, sondern kann auch clientseitig in Cookies gespeichert werden, die in den meisten Fällen verschlüsselt sind. Zum Beispiel macht das PHP CodeIgniter-Framework dies standardmäßig. Es gibt eine Reihe von Mechanismen zum Schützen der Sitzung auf der Clientseite, und ich sehe diese Art des Speicherns von Sitzungsdaten nicht weniger sicher als das Speichern sessionId, die dann im Sitzungsspeicher auf der Serverseite nachgeschlagen wird. Das Speichern auf der Sitzungsclientseite ist auch in verteilten Umgebungen sehr praktisch, da keine Lösung für das zentrale Sitzungsmanagement auf der Serverseite entworfen (oder bereits vorhandene verwendet) werden muss .

Darüber hinaus muss die Authentifizierung mit einem einfachen Benutzer-Passwort-Paar nicht in jedem Fall über einen benutzerdefinierten Code erfolgen, der nach passenden Benutzerdatensätzen in der Datenbank sucht. Es gibt zum Beispiel Basisauthentifizierungsprotokoll oder Digestauthentifizierung . Bei proprietärer Software wie der Windows-Plattform gibt es auch Möglichkeiten zur Authentifizierung von Benutzern, z. B. ActiveDirectory

Wenn Sie ein Benutzername/Passwort-Paar angeben, können Sie sich nicht nur authentifizieren. Wenn Sie das HTTPS-Protokoll verwenden, können Sie auch die Authentifizierung in Betracht ziehen nter Verwendung digitaler Zertifikate .

In bestimmten Anwendungsfällen gibt es beim Entwerfen von Webdiensten, die SOAP als Protokoll verwenden, auch die Erweiterung WS-Security für SOAP Protokoll.

Nach alledem würde ich sagen, dass die Antworten auf die folgende Frage in das Entscheidungsverfahren für die Auswahl des Autorisierungs-/Authentifizierungsmechanismus für WebApi eingehen:

1) Was ist die Zielgruppe, ist sie öffentlich zugänglich oder nur für registrierte (zahlende) Mitglieder?
2) Wird es ausgeführt oder * NIX oder MS-Plattform
3) Wie viele Benutzer werden erwartet?
4) Wie viel vertrauliche Daten werden von der API verarbeitet (stärkere gegenüber schwächeren Authentifizierungsmechanismen)
5) Gibt es einen SSO-Dienst, den Sie verwenden können?

.. und viele mehr.

Hoffe, dass dies die Dinge etwas klärt, da es viele Variablen in der Gleichung gibt.

9
toske

Wenn die API-basierte APP ein Client ist, muss die API die Option haben, die Cookies vom Server-Antwortdatenstrom abzurufen/zu lesen und zu speichern. Zum automatischen Anhängen von Cookies während der Vorbereitung des Anforderungsobjekts für denselben Server/dieselbe URL. Wenn es nicht verfügbar ist, kann die Sitzungs-ID nicht abgerufen werden.

1
Bharath

Ich würde vorschlagen, dass Sie bei jeder Anfrage eine Art Token senden.

Abhängig von Server und Service kann dies ein JSESSIONID -Parameter in Ihrer GET/POST-Anfrage sein oder etwas ausgereiftes wie SAML in SOAP über HTTP in Ihrer Web-Service-Anfrage.

1
iga

Sie haben Recht, der Grund, warum die Dinge in einer Standardumgebung "automatisch" sind, ist, dass Cookies der URL-Weitergabe vorgezogen werden, um die Dinge für die Benutzer hübsch zu halten. Das heißt, der Browser (Client-Software) verwaltet das Speichern und Senden des Sitzungscookies zusammen mit jeder Anforderung.

In der API-Welt werden bei einfachen Systemen häufig nur Authentifizierungsinformationen mit jeder Anforderung weitergegeben (zumindest in meinem Tätigkeitsbereich). Kundenautoren zögern normalerweise (wieder nach meiner Erfahrung), die Speicherung und Übertragung von Cookies bei jeder Anfrage und im Allgemeinen bei allem, was über das Nötigste hinausgeht, zu implementieren ...

Es gibt viele andere Authentifizierungsmechanismen für HTTP-basierte APIs, HTTP Basic/Digest, um nur einige zu nennen, und natürlich die allgegenwärtige O-Authentifizierung, die speziell für diese Dinge entwickelt wurde, wenn ich mich nicht irre. Es werden keine Cookies gespeichert, Anmeldeinformationen sind Teil jedes Austauschs (ziemlich sicher).

Die andere zu berücksichtigende Sache ist, was Sie mit der Sitzung auf dem Server in einer API tun werden. Die Sitzung auf einer Website bietet Speicherplatz für den aktuellen Benutzer und speichert normalerweise kleine Datenmengen, um die Datenbank von Seite zu Seite zu entlasten. In einem API-Kontext ist dies weniger notwendig, da die Dinge mehr oder weniger zustandslos sind, was im Allgemeinen natürlich gilt. Es hängt wirklich davon ab, was der Dienst tut.

1
quickshiftin