Moin!

Ich habe da mal eine grundsätzliche Frage zu Session-IDs und HTTP-Auth.
So ganz bin ich mir nicht sicher, welche der beiden Methoden ich
nutzen soll, um Benutzer zu authentifizieren. Die gesamte Benutzer-
session ist durch HTTPS abgesichert, mir stellt sich nur die Frage,
welche der beiden Methoden einfacher ist. Bei Session-IDs muss ich an
jeden Link und in Formularen eine Session-ID anhängen, bei HTTP-Auth
wird mir diese Arbeit abgenommen. Somit fällt meine erste Wahl auf
HTTP-Auth, aber welche Nachteile gibt es hier?

Wenn man beide Methoden vergleicht, gibt es aus Benutzersicht nur einen einzigen Unterschied: Bei HTTP-Auth kommt ein (vom Seitenautor nicht designbares) Passwortfenster des Browsers, bei Session-Logins steht irgendwo in der Seite ein (vermutlich designtes) Formular.

Aus Anbietersicht kann diese Designbarkeitsfrage schon ausschlaggebend sein.

Auf der anderen Seite: Wenn man HTTP-Auth für ein Verzeichnis definiert, sind automatisch alle Inhalte dort (auch Bilder und sonstige Ressourcen) geschützt. Bei Session-Logins gilt dies nur für die Ressourcen, die ein Skript starten, welches (hoffentlich) auf korrekte Weise und unumgehbar prüft, ob der User berechtigt ist.

Deine Aussage hinsichtlich der Platzierung der Session-ID ist übrigens nicht ganz korrekt: PHP kann das auch komplett selbst übernehmen, wenn man es entsprechend konfiguriert. Andererseits wäre es ohnehin besser, sich in diesem Fall lieber nur ausschließlich auf die Session-ID in Cookies zu verlassen und das Zulassen von Cookies einfach als Mindestzugangsvoraussetzung vom User zu fordern. Dann kann er nicht aus Versehen die Session-ID aus der URL an Dritte weitergeben, die dann die Session übernehmen, ohne sich anzumelden.

In der Summe: HTTP-Auth ist eher als "technisch" anzusehen, liefert auf extrem einfache Weise einen sicheren Schutz, ist aber optisch und vom Handling her nicht unbedingt die ideale Lösung für die Benutzer. Session-Login hingegen erfordert die eigenständige und 100% korrekte Umsetzung eines Login-Systems, ist deshalb natürlich auch wesentlich flexibler, was z.B. Userrechte und -gruppen angeht, und auch optisch etwas userkompatibler, schützt aber nicht automatisch andere Ressourcen - die deshalb eventuell durch entsprechende Skripte, die die Daten von einem per HTTP(S) unerreichbaren Ort aus "durchreichen", was dummerweise Performance kostet.

- Sven Rautenberg