Wir alle lieben es, dass wir uns in nativen Apps nur einmal anmelden müssen und dann gespeichert werden, bis wir uns abmelden. Leider funktioniert das im Web nicht immer so.
Da Geräte, insbesondere Mobilgeräte, immer persönlicher werden und immer mehr Websites den gesamten Traffic über HTTPS senden, um das Risiko von Tokendiebstahl zu verringern, sollten Websites ihre Richtlinien zu kurzlebigen Cookies überdenken und nutzerfreundlichere, länger andauernde Sitzungen einführen.
Auch wenn Sie die Sitzung verlängern möchten, prüfen einige Websites die Authentifizierung des Nutzers nicht bei jeder Anfrage. Mit anderen Worten: Es gibt keine Möglichkeit, das Sitzungscookie nach dem Ausstellen aufzuheben. Das führt normalerweise zu kurzen Sitzungen, da sich der Nutzer häufig anmelden muss, damit seine Authentifizierung noch einmal bestätigt werden kann. So können z. B. vorhandene Sitzungen nach einer Passwortänderung nach einer bestimmten Zeit ungültig werden.
Wenn Sie diesen Ansatz verwenden, haben wir eine technische Lösung, mit der Sie das zustandslose Authentifizierungs-Cookie automatisch noch einmal validieren können. Dazu wird ein sekundäres langlebiges Token verwendet, mit dem das vorhandene kurzlebige Authentifizierungs-Cookie aktualisiert werden kann. Durch die Nutzung des neuen Service Worker-Musters können wir uns regelmäßig mit dem langlebigen Token anmelden, die Authentifizierung des Nutzers überprüfen (z. B. prüfen, ob er sein Passwort in letzter Zeit nicht geändert oder die Sitzung anderweitig widerrufen hat) und ein neues kurzlebiges Authentifizierungs-Cookie ausstellen.
Ein praktischer Vorschlag für die Migration zu sicheren, langen Sitzungen im Web
Im Folgenden wird eine neue Methode beschrieben, die wir 2-Cookie-Übergabe (2CH) nennen. Wir hoffen, dass wir mit diesem Artikel Feedback von der Community dazu erhalten, ob dieser Ansatz positiv erscheint. Falls ja, möchten wir gemeinsam mit der Branche Best Practices für die Verwendung von 2CH dokumentieren.
Service Worker sind eine neue Technologie, die von mehreren Browsern wie Chrome, Firefox und Opera unterstützt wird und bald auch in Edge verfügbar sein wird. Sie können damit alle Netzwerkanfragen von Ihrer Website über einen gemeinsamen Codepunkt auf dem Client abfangen, ohne die vorhandenen Seiten zu ändern. So können Sie für angemeldete Nutzer einen „2CH-Worker“ einrichten, der alle Netzwerkanfragen Ihrer Seite abfangen und den Token-Swap wie bei mobilen Apps ausführen kann.
In den meisten Fällen hat Ihr Server bereits einen Endpunkt, über den mobile Apps ein neues kurzlebiges Token abrufen, in der Regel über das OAuth-Protokoll. Um das oben beschriebene Muster im Web zu aktivieren, muss dieser Endpunkt nur so aktualisiert werden, dass er erkennt, wann er von einem Service Worker aufgerufen wird, und dann ein neues kurzlebiges Sitzungs-Cookie zurückgibt, das so formatiert ist, wie es andere Seiten auf der Website bereits erwarten.
Wenn Ihr Server noch keinen solchen Endpunkt hat, kann er einen nur für die Browsersitzionsverwaltung erstellen.
Das Zwei-Token-Muster mit Dienstmitarbeitern folgt dem OAuth 2.0-Muster ziemlich genau. Wenn Sie bereits einen OAuth-Token-Endpunkt verwenden, können Sie ihn wahrscheinlich mit Dienstmitarbeitern für Ihre Webauthentifizierung wiederverwenden.
Vielleicht fragen Sie sich auch, was passiert, wenn der Nutzer einen Browser verwendet, der keine Service Worker unterstützt. Wenn Sie den oben beschriebenen Ansatz implementieren, werden sie keinen Unterschied feststellen und weiterhin kurze Sitzungen haben.
Wir haben einen Beispielclient und ein Beispiel-Backend veröffentlicht. Wir hoffen, dass Sie das Tool selbst ausprobieren und an einer Umfrage zur Sitzungsverwaltung teilnehmen.