PHP Authentifizierung: Sessions, JWT und Remember-Me

Kaum ein Thema begleitet die Webentwicklung so durchgehend wie die Frage, wie sich Benutzer sicher anmelden und über viele Seitenaufrufe hinweg zuverlässig erkannt werden. Dieses Tutorial gibt einen praxisnahen Überblick über die wichtigsten Verfahren und hilft dabei, für das eigene Projekt die passende Strategie zu wählen.

Was ist PHP Authentifizierung?

In jeder Webanwendung mit Login muss die Frage beantwortet werden, welcher Benutzer hinter der Tastatur sitzt. Genau das ist PHP Authentifizierung: ein Mechanismus, der die Identität eines Benutzers feststellt und über den Request hinweg behält. Nicht zu verwechseln mit Autorisierung, die regelt, was der eingeloggte Benutzer machen darf.

Die folgende Tour vergleicht Sessions, JWT und Remember-Me und liefert am Ende eine Entscheidungsmatrix für den richtigen Ansatz im jeweiligen Projekt.

Für die Authentifizierung selbst stehen mehrere Strategien zur Auswahl. Drei Varianten sind in der Praxis besonders verbreitet: das klassische Server-State-Modell mit Sessions, der stateless-Ansatz mit JSON Web Tokens und die hybride Variante mit Remember-Me-Cookies. Dieses Tutorial vergleicht die drei Methoden, zeigt jede in einem Mini-Beispiel und liefert eine Entscheidungsmatrix, damit die Wahl bewusst statt aus Reflex erfolgt. Bevor es losgeht, lohnt ein Blick auf das Fundament jeder Passwort-Authentifizierung und auf den typischen Login-Flow.

Passwort-Hashing als Grundlage: password_hash und password_verify

Egal welche Strategie später folgt, die PHP Authentifizierung beginnt fast immer mit einem Passwort. Klartext-Passwörter haben in der Datenbank nichts verloren. PHP liefert mit password_hash() einen sicheren Algorithmus mit, der per Default auf bcrypt setzt und ab PHP 7.4 auch Argon2id unterstützt.

<?php

/* beim Registrieren: das eingegebene Passwort hashen */

$hash = password_hash($_POST['password'], PASSWORD_DEFAULT);

$pdo->prepare('INSERT INTO users (email, password_hash) VALUES (?, ?)')

 ->execute([$_POST['email'], $hash]);



/* beim Login: Hash aus DB holen, vergleichen */

$row = $pdo->prepare('SELECT id, password_hash FROM users WHERE email = ?');

$row->execute([$_POST['email']]);

$user = $row->fetch(PDO::FETCH_ASSOC);



if ($user && password_verify($_POST['password'], $user['password_hash'])) {

 /* Passwort stimmt. Bei Bedarf neu hashen, falls Algorithmus veraltet */

 if (password_needs_rehash($user['password_hash'], PASSWORD_DEFAULT)) {

 $neuerHash = password_hash($_POST['password'], PASSWORD_DEFAULT);

 $pdo->prepare('UPDATE users SET password_hash = ? WHERE id = ?')

 ->execute([$neuerHash, $user['id']]);

 }

}

password_hash() erzeugt automatisch ein eigenes Salt pro Hash und integriert dieses in den Rückgabewert. Eigene Salt-Logik ist daher überflüssig und sogar schädlich. password_verify() liest das eingebettete Salt heraus und vergleicht zeitkonstant. Das Ergebnis: keine Timing-Angriffe, keine Rainbow-Tables, kein Reverse-Engineering aus dem Hash.

Login-Flow Schritt für Schritt

Damit die einzelnen Bausteine im Zusammenspiel klar werden, lohnt sich ein vollständiger Login-Flow als roter Faden. Der typische Weg in der PHP Authentifizierung besteht aus sechs Schritten.

<?php

/*

 * 1. Eingaben aus dem Formular einlesen und validieren

 * 2. Account zur E-Mail per Prepared Statement laden

 * 3. password_verify() gegen den DB-Hash pruefen

 * 4. Bei Erfolg session_regenerate_id(true) gegen Fixation

 * 5. user_id in $_SESSION ablegen, ggf. last_login schreiben

 * 6. Redirect auf geschuetzte Seite

 */

session_start();



$email = filter_input(INPUT_POST, 'email', FILTER_VALIDATE_EMAIL);

if (!$email) { exit('E-Mail ungueltig.'); }



$stmt = $pdo->prepare('SELECT id, password_hash FROM users WHERE email = ?');

$stmt->execute([$email]);

$user = $stmt->fetch(PDO::FETCH_ASSOC);



if ($user && password_verify($_POST['password'] ?? '', $user['password_hash'])) {

 session_regenerate_id(true);

 $_SESSION['user_id'] = (int) $user['id'];

 $_SESSION['login_at'] = time();

 header('Location: /dashboard.php');

 exit;

}



/* Generische Fehlermeldung, keine Account-Enumeration */

exit('Login fehlgeschlagen.');

Wichtig: niemals zurückmelden, ob die E-Mail existiert oder ob nur das Passwort falsch war. Beide Fälle bekommen denselben generischen Text. Ohne diese Disziplin laden Angreifer Wortlisten und probieren reihenweise Konten durch, bis sie eine valide E-Mail-Adresse finden. Mehr Hintergrund zu CSRF-Token, Bruteforce-Bremse und Remember-Me liefert das eigene Tutorial PHP Login-System bauen.

Sessions: das klassische Server-State-Modell

Sessions sind der Default-Weg für PHP Authentifizierung. Der Server hält die Daten zum eingeloggten Nutzer in $_SESSION, der Browser bekommt nur einen Cookie mit der Session-ID. Bei jedem Request schickt der Browser die ID mit, der Server schaut nach, welcher Nutzer dazu gehört.

<?php

session_start();

if (password_verify($_POST['password'], $hashAusDb)) {

 session_regenerate_id(true);

 $_SESSION['user_id'] = $userId;

 /* ab jetzt ist der User eingeloggt */

}

Vorteile: einfach, robust, keine Krypto-Stolperfallen. Nachteile: Server muss Session-Daten speichern, in horizontal skalierten Setups braucht es einen geteilten Session-Store (Redis, DB). Die Session-ID muss mit session_regenerate_id() rotiert werden, sonst wird die PHP Authentifizierung anfällig für Session-Fixation. Den dazugehörigen Login-Flow mit Bruteforce-Bremse und CSRF-Token zeigt das Tutorial PHP Login-System bauen.

JWT als PHP Authentifizierung: Stateless-Token für APIs

PHP Authentifizierung mit JWT folgt einer ganz anderen Logik. JSON Web Tokens kehren das Modell der PHP Authentifizierung um. Der Server gibt nach erfolgreichem Login ein signiertes Token aus, das alle relevanten Claims enthält. Bei jedem Request schickt der Client das Token mit (Cookie oder Authorization: Bearer ...). Der Server prüft die Signatur und liest die Claims, ohne eine eigene State-Tabelle zu brauchen.

<?php

function base64UrlEncode(string $data): string {

 return rtrim(strtr(base64_encode($data), '+/', '-_'), '=');

}



$header = ['alg' => 'HS256', 'typ' => 'JWT'];

$payload = ['sub' => $userId, 'exp' => time() + 900];

$secret = 'streng-geheimes-server-passwort';



$h = base64UrlEncode(json_encode($header));

$p = base64UrlEncode(json_encode($payload));

$signature = hash_hmac('sha256', "$h.$p", $secret, true);

$token = $h . '.' . $p . '.' . base64UrlEncode($signature);

Die Verifikation auf Empfangsseite folgt dem gleichen Prinzip. Wichtig ist, die Signatur mit hash_equals() zu vergleichen, sonst sind Timing-Angriffe möglich.

<?php

$parts = explode('.', $token);

if (count($parts) !== 3) { exit('ungueltig'); }



[$h, $p, $s] = $parts;

$expected = hash_hmac('sha256', "$h.$p", $secret, true);

$encoded = base64UrlEncode($expected);



if (!hash_equals($s, $encoded)) {

 exit('Signatur falsch');

}

$payload = json_decode(base64_decode(strtr($p, '-_', '+/')), true);

if (($payload['exp'] ?? 0) < time()) {

 exit('Token abgelaufen');

}

JWT spielt seine Stärken in REST-APIs aus, vor allem dann, wenn der Server keine Session-State halten soll oder wenn unterschiedliche Microservices dieselbe Identität prüfen müssen. Für einen klassischen Webseiten-Login ist JWT meist Overkill und bringt mehr Probleme als Lösungen.

Remember-Me als PHP Authentifizierung: Hybrid mit Token in DB

PHP Authentifizierung mit Remember-Me kombiniert Komfort und Sicherheit. Der dritte Weg ist eine Mischung. Nach dem Login bekommt der Nutzer einen langlebigen Cookie, der einen Selector und einen Token enthält. Der Server speichert nur den Hash des Tokens in einer DB-Tabelle. Beim nächsten Besuch läuft Auto-Login: Selector-Lookup, Token-Hash vergleichen, Session aufbauen.

<?php

/*

 * Remember-Me-Cookie:

 * - Selector + Token (random_bytes)

 * - Server speichert hash($token), Client speichert $selector:$token

 * - bei Auto-Login: Selector lookup, hash_equals des gespeicherten Hashs

 *

 * Vollstaendiges Beispiel: siehe Tutorial PHP Login-System.

 */

Damit hat man das Beste beider Welten: kurzlebige Sessions für den eigentlichen Auth-Zustand und einen langlebigen Cookie für den Wiederbesuch. Der Cookie sollte zwingend HttpOnly, Secure und SameSite=Strict haben, der Token sollte nie im Klartext gespeichert werden. Diese Variante lässt sich gut mit klassischer Session-Auth kombinieren und ist für typische Webseiten der pragmatischste Weg, einen permanenten Login zu bauen.

Entscheidungsmatrix für PHP Authentifizierung: Session vs. JWT vs. Remember-Me

Welche Methode der PHP Authentifizierung passt nun zu welchem Projekt? Die folgende Übersicht hilft bei der Auswahl.

Pragmatisch heißt das: Wer eine klassische Webseite oder eine SPA mit Same-Origin-Backend baut, ist mit Sessions am schnellsten am Ziel. Wer eine REST-API für Mobile-Apps oder Dritt-Clients liefert, profitiert von JWT. Wer permanent eingeloggte Nutzer haben möchte, ergänzt Sessions um Remember-Me. Mehr Implementierungs-Details liefert das Tutorial PHP Login-System bauen.

JWT-Stolperfallen bei PHP Authentifizierung: Refresh und Revocation

Beim Einsatz von JWT in der PHP Authentifizierung lauern zwei Tücken. JWT klingt elegant, hat aber zwei harte Probleme. Erstens die Revocation: ein einmal ausgegebenes Token bleibt bis zum Ablauf gültig, auch wenn der Nutzer abgemeldet werden soll. Lösen kann man das nur mit einem serverseitigen Blacklist- oder Whitelist-Mechanismus, was den Stateless-Vorteil teilweise neutralisiert.

Zweitens der Refresh-Mechanismus: kurzlebige Access-Tokens (etwa 15 Minuten) sollen das Schadensrisiko bei Diebstahl klein halten. Damit der Nutzer nicht alle 15 Minuten neu einloggen muss, gibt es ein langlebiges Refresh-Token. Dessen sichere Speicherung (HttpOnly-Cookie) und Rotation (jedes Refresh erzeugt einen neuen Refresh-Token, alte werden invalidiert) sind Pflichtprogramm und nicht trivial.

<?php

/*

 * Empfehlung fuer JWT-Setups:

 * - Access-Token kurzlebig (5-15 Minuten), im Authorization-Header

 * - Refresh-Token langlebig (Tage), in HttpOnly-Cookie, in DB rotiert

 * - alg in Library hart auf "HS256" oder "RS256" setzen, niemals alg=none akzeptieren

 */

Wer die JWT-Konstruktion selbst baut, sollte unbedingt eine etablierte Bibliothek wie firebase/php-jwt nutzen. Eigenbau-Implementierungen sind klassische Quellen für Algorithm-Confusion-Bugs.

Zwei-Faktor-Authentifizierung mit TOTP (Google Authenticator)

Eine starke Ergänzung der PHP Authentifizierung ist der zweite Faktor. Klassisch geschieht das per TOTP, also einem zeitbasierten Einmal-Code, den der Authenticator-App des Nutzers aus einem geteilten Secret berechnet. Server und App teilen das gleiche Secret und leiten daraus alle 30 Sekunden den gleichen sechsstelligen Code ab. Der Code wird nach erfolgreichem Passwort-Login als zweiter Schritt abgefragt.

<?php

/* TOTP-Verifikation in wenigen Zeilen, RFC 6238 */

function totp(string $secretBase32, int $zeitfenster = 0): string {

 $secret = '';

 $alphabet = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ234567';

 foreach (str_split(strtoupper($secretBase32)) as $char) {

 $secret .= str_pad(decbin(strpos($alphabet, $char)), 5, '0', STR_PAD_LEFT);

 }

 $bytes = '';

 foreach (str_split($secret, 8) as $bin) {

 if (strlen($bin) === 8) { $bytes .= chr(bindec($bin)); }

 }



 $counter = pack('N*', 0) . pack('N*', floor(time() / 30) + $zeitfenster);

 $hash = hash_hmac('sha1', $counter, $bytes, true);

 $offset = ord($hash[19]) & 0xf;

 $code = (

 ((ord($hash[$offset]) & 0x7f) << 24) |

 ((ord($hash[$offset + 1]) & 0xff) << 16) |

 ((ord($hash[$offset + 2]) & 0xff) << 8) |

 (ord($hash[$offset + 3]) & 0xff)

 ) % 1000000;



 return str_pad((string) $code, 6, '0', STR_PAD_LEFT);

}



/* Vergleich mit hash_equals, Toleranz fuer +/- 1 Zeitfenster */

$eingabe = $_POST['totp'] ?? '';

$ok = hash_equals(totp($user['totp_secret'], -1), $eingabe)

 || hash_equals(totp($user['totp_secret'], 0), $eingabe)

 || hash_equals(totp($user['totp_secret'], +1), $eingabe);

In der Praxis greift man besser zu einer etablierten Bibliothek wie pragmarx/google2fa oder spomky-labs/otphp, die zusätzlich QR-Code-Generierung und Recovery-Codes mitbringen. Wichtig: das TOTP-Secret pro Nutzer in der Datenbank speichern, idealerweise verschlüsselt. Der zweite Faktor wird erst nach erfolgreicher Passwort-Prüfung abgefragt, und erst die positive TOTP-Verifikation setzt $_SESSION['user_id']. Bis dahin bleibt der Login-Status in einer Zwischen-Variable wie $_SESSION['pending_user_id'].

WebAuthn und Passkeys: passwortlose PHP Authentifizierung

WebAuthn ist der moderne Standard für passwortlose PHP Authentifizierung. Statt eines Passworts hält das Endgerät (Smartphone, Yubikey, Touch-ID) einen privaten Schlüssel, der Server speichert nur den öffentlichen Schlüssel. Beim Login schickt der Server eine Challenge, das Gerät signiert sie und der Server prüft die Signatur. Phishing-Angriffe greifen ins Leere, weil das Gerät die Origin-URL in die Signatur einbezieht.

<?php

/*

 * Eigenbau ist hier ein schlechter Plan. Erprobt sind:

 * composer require web-auth/webauthn-lib

 *

 * Grober Ablauf bei Registrierung:

 * 1. Server erzeugt PublicKeyCredentialCreationOptions (Challenge + RP-Id)

 * 2. Browser ruft navigator.credentials.create()

 * 3. Server prueft die Antwort und speichert die Credential-Id + Public-Key

 *

 * Login (Authentication):

 * 1. Server erzeugt PublicKeyCredentialRequestOptions

 * 2. Browser signiert mit navigator.credentials.get()

 * 3. Server verifiziert Signatur gegen den gespeicherten Public-Key

 */

Passkeys sind die End-User-Verpackung von WebAuthn: der Schlüssel synchronisiert sich über iCloud-Schlüsselbund, Google Password Manager oder einen externen Manager und ist damit auf mehreren Geräten verfügbar. Für Webseiten bedeutet das: Nutzer müssen sich kein Passwort merken, Phishing wird massiv erschwert und Passwort-Reset-Flows werden überflüssig. Für PHP-Projekte gibt es mit web-auth/webauthn-lib eine ausgereifte Bibliothek, die beide Seiten (Registrierung und Login) abdeckt.

HTTP Basic und Digest Auth in PHP

Neben Sessions, JWT und Co. kennt PHP noch die alten Bekannten der HTTP-Authentifizierung. HTTP Basic Auth wird vom Server selbst abgefragt, der Browser zeigt einen nativen Login-Dialog. PHP liest die Daten aus den Server-Variablen $_SERVER['PHP_AUTH_USER'] und $_SERVER['PHP_AUTH_PW'].

<?php

if (!isset($_SERVER['PHP_AUTH_USER'])) {

 header('WWW-Authenticate: Basic realm="Geschuetzter Bereich"');

 header('HTTP/1.0 401 Unauthorized');

 exit('Authentifizierung erforderlich.');

}



if ($_SERVER['PHP_AUTH_USER'] === 'admin'

 && password_verify($_SERVER['PHP_AUTH_PW'], $hashAusDb)) {

 echo 'Eingeloggt als ' . htmlspecialchars($_SERVER['PHP_AUTH_USER']);

} else {

 header('HTTP/1.0 401 Unauthorized');

 exit('Login falsch.');

}

Basic Auth schickt das Passwort base64-codiert mit jedem Request, also unbedingt nur über HTTPS einsetzen. Digest Auth (PHP_AUTH_DIGEST) ist die kryptographisch härtere Variante, in der Praxis aber wenig verbreitet und für moderne Webanwendungen meist ungeeignet, weil eine echte Logout-Funktion fehlt und keine Anpassbarkeit am Login-Dialog möglich ist. Sinnvolle Einsatzfelder bleiben interne Admin-Tools, einfache REST-Endpunkte hinter Reverse-Proxy oder schnelle Schutzmechanismen für Staging-Umgebungen.

LDAP und Active Directory anbinden

In Unternehmensumgebungen sitzt die Identität oft im Verzeichnisdienst, also in einem LDAP-Server oder im Active Directory. PHP bringt mit der ldap_*-Funktionsfamilie eine direkte Anbindung mit. Der typische Bind-Login besteht aus zwei Schritten: erst die Verbindung herstellen, dann mit den Nutzer-Credentials gegen den DN binden.

<?php

$ldap = ldap_connect('ldaps://ad.firma.local');

ldap_set_option($ldap, LDAP_OPT_PROTOCOL_VERSION, 3);

ldap_set_option($ldap, LDAP_OPT_REFERRALS, 0);



$user = $_POST['user'] ?? '';

$pass = $_POST['pass'] ?? '';



/* Bei AD reicht oft der UPN: user@firma.local */

if (@ldap_bind($ldap, "$user@firma.local", $pass)) {

 /* User ist gegen das AD authentifiziert.

 * Optional Gruppen-Mitgliedschaft pruefen, dann Session aufbauen. */

 $_SESSION['user_id'] = $user;

} else {

 exit('LDAP-Login fehlgeschlagen.');

}

Sicherheitskritisch sind drei Punkte: erstens immer ldaps:// oder StartTLS nutzen, sonst geht das Passwort im Klartext durch das Netzwerk. Zweitens die Eingabe-Strings escapen, damit niemand über LDAP-Injection einen alternativen DN konstruiert. Drittens die Autorisierung sauber trennen: ein erfolgreiches Bind sagt nur, dass das Passwort stimmt, aber nicht, ob der Nutzer in der berechtigten Gruppe ist. Die Gruppenprüfung erfolgt über einen zusätzlichen ldap_search-Aufruf nach dem Bind.

Session-Fixation und Session-Hijacking abwehren

Sessions sind nur so sicher wie die Schutzmassnahmen drumherum. Session-Fixation bedeutet, dass ein Angreifer dem Opfer eine bekannte Session-ID unterschiebt (etwa per präparierten Link mit ?PHPSESSID=...). Wenn das Opfer sich dann einloggt, kennt der Angreifer die gültige ID. Schutz: konsequent session_regenerate_id(true) direkt nach dem erfolgreichen Login aufrufen, damit eine neue ID vergeben wird.

Session-Hijacking ist der Diebstahl einer aktiven Session-ID, etwa per XSS oder per ungeschütztem WLAN. Schutz: HTTPS plus die richtigen Cookie-Flags und ein Idle-Timeout.

<?php

/* Session-Cookie haerten - vor session_start() setzen */

session_set_cookie_params([

 'lifetime' => 0,

 'path' => '/',

 'secure' => true,

 'httponly' => true,

 'samesite' => 'Lax',

]);

session_start();



/* Optional: Idle-Timeout nach 30 Minuten ohne Aktivitaet */

if (isset($_SESSION['last_seen']) && (time() - $_SESSION['last_seen']) > 1800) {

 session_unset();

 session_destroy();

 header('Location: /login.php?reason=timeout');

 exit;

}

$_SESSION['last_seen'] = time();

HttpOnly verhindert, dass JavaScript den Cookie auslesen kann. Secure schickt den Cookie nur über HTTPS. SameSite=Lax blockiert die meisten CSRF-Vektoren. Eine zusätzliche IP-Bindung ($_SESSION['ip']) klingt verlockend, stört aber Mobilfunk-Nutzer mit wechselnden IPs und liefert nur scheinbare Sicherheit. Besser ist eine Bindung an den User-Agent oder ein zusätzlicher Verifizierungs-Cookie.

Hybride Architekturen der PHP Authentifizierung und OAuth/OpenID Connect

PHP Authentifizierung in größeren Setups ist selten monolithisch. In größeren Systemen kombinieren Teams oft mehrere Strategien. Die Webseite nutzt Sessions, die mobile App nutzt JWT, und Service-to-Service-Calls verwenden client-credential-Tokens. Das ist legitim, solange die Bruchstellen sauber definiert sind und die User-Identität zwischen den Welten konsistent bleibt.

Für Single-Sign-On greifen viele Projekte zu OAuth 2.0 mit OpenID Connect. Wichtig: OAuth alleine ist nicht zur Authentifizierung gedacht, sondern ein Autorisierungs-Framework. OpenID Connect ist die ID-Erweiterung darauf und liefert ein ID-Token, das den Nutzer identifiziert. Wer SSO an Microsoft 365, Google oder Keycloak braucht, kommt um OpenID Connect nicht herum, sollte aber auf etablierte Bibliotheken wie league/oauth2-client setzen.

flowchart TD
    A[Login Request] --> B{Auth-Strategie}
    B -->|Session| C[Server haelt Daten]
    B -->|JWT| D[Token traegt Claims]
    B -->|Remember-Me| E[Selector + Token in DB]
    C --> F[Cookie mit Session-ID]
    D --> G[Cookie oder Authorization-Header]
    E --> H[Cookie + DB-Lookup]

Fazit zu PHP Authentifizierung

PHP Authentifizierung ist keine Glaubensfrage, sondern eine Entscheidung mit klaren Kriterien. Sessions sind der pragmatische Default für Webseiten und SPAs mit Same-Origin-Backend, JWT spielt seine Stärken in REST-APIs und Microservice-Architekturen aus, Remember-Me ergänzt Sessions für einen komfortablen Wiederbesuch. Wer JWT einsetzt, muss Refresh- und Revocation-Strategie sauber durchdenken und auf etablierte Bibliotheken setzen. Wer Sessions nutzt, achtet auf session_regenerate_id, sichere Cookie-Flags und einen Session-Store für skalierte Setups. PHP Authentifizierung wird damit zu einer Architektur-Entscheidung, die mit dem Projekt mitwachsen kann, statt zu einer Reflex-Entscheidung im ersten Sprint.