Wir alle finden es toll, dass systemeigene Apps Sie nur einmal zur Anmeldung auffordern und sich dann an Sie erinnern, bis Sie ihnen sagen, dass Sie sich abmelden möchten. Leider funktioniert das Web nicht immer so.
Da Geräte, insbesondere Mobilgeräte, persönlicher sind und immer mehr Websites den gesamten Traffic über HTTPS senden, wodurch sich das Risiko von Tokendiebstahl verringert, sollten Websites ihre kurzlebigen Cookie-Richtlinien überdenken und nutzerfreundlichere Sitzungen mit längerer Lebensdauer einführen.
Aber auch wenn Sie die Sitzung länger halten möchten, überprüfen einige Websites die Authentifizierung des Nutzers nicht bei jeder Anfrage. Es gibt also keine Möglichkeit, das Sitzungscookie nach der Ausgabe zu widerrufen. Dies führt in der Regel zu kurzen Sitzungen, in denen der Nutzer sich häufig anmelden muss, damit seine Authentifizierung neu validiert werden kann. So können Dinge wie eine Passwortänderung vorhandene Sitzungen in einem bekannten Zeitraum ungültig machen.
Wenn Sie diesen Ansatz verwenden, haben wir eine technische Lösung, mit der Sie das zustandslose Authentifizierungscookie automatisch noch einmal validieren können. Dazu wird ein sekundäres langlebiges Token verwendet, mit dem Ihr vorhandenes kurzlebiges Authentifizierungscookie aktualisiert werden kann. Die Nutzung des neuen Service Worker-Musters ermöglicht es uns, regelmäßig mit dem langlebigen Token einzuchecken, die Authentifizierung des Nutzers zu überprüfen (z. B. um zu prüfen, ob er nicht kürzlich sein Passwort geändert oder die Sitzung anderweitig widerrufen hat) und ein neues kurzlebiges Authentifizierungscookie ausgeben zu können.
Ein praktischer Vorschlag für die Migration zu sicheren langen Sitzungen im Web
In diesem Beitrag wird eine neue, von uns vorgeschlagene Methode 2-Cookie-Handoff (2CH) beschrieben. Wir freuen uns auf die Nutzung dieses Artikels, um von der Community Feedback dazu zu erhalten, ob dieser Ansatz positiv erscheint, und gegebenenfalls in Zusammenarbeit mit der Branche Best Practices für die Verwendung von 2CH zu dokumentieren.
Service Worker sind eine neue Technologie, die von verschiedenen Browsern wie Chrome, Firefox und Opera unterstützt wird und demnächst in Edge verfügbar ist. Sie ermöglichen es Ihnen, alle Netzwerkanfragen von Ihrer Website über einen gemeinsamen Codepunkt auf dem Client abzufangen, ohne die vorhandenen Seiten zu ändern. Auf diese Weise können Sie einen „2CH-Worker“ für angemeldete Nutzer einrichten, der alle von Ihrer Seite gesendeten Netzwerkanfragen abfangen und den Token-Austausch wie mobile Apps durchführen kann.
In den meisten Fällen hat Ihr Server bereits einen Endpunkt, der von mobilen Apps verwendet wird, um ein neues kurzlebiges Token abzurufen, das normalerweise das OAuth-Protokoll verwendet. Um das obige Muster im Web zu aktivieren, muss dieser Endpunkt nur aktualisiert werden, um zu verstehen, wann er von einem Service Worker aufgerufen wird, und dann ein neues kurzlebiges Sitzungscookie zurückzugeben, das so formatiert ist, dass andere Seiten auf der Website es bereits erwarten.
Wenn Ihr Server noch keinen solchen Endpunkt hat, kann er einen nur für die Browsersitzungsverwaltung erstellen.
Das Zwei-Token-Muster mit Service Workern folgt ziemlich genau dem OAuth 2.0-Muster. Wenn Sie bereits einen OAuth-Token-Endpunkt ausführen, können Sie ihn wahrscheinlich mit Service Workern für Ihre Webauthentifizierung wiederverwenden.
Sie fragen sich vielleicht auch, was passiert, wenn der Nutzer einen Browser aufruft, der keine Service Worker unterstützt. Wenn Sie den obigen Ansatz umsetzen, gibt es keinen Unterschied und die Sitzungen bleiben trotzdem kurz.
Wir haben einen Beispielclient und ein Beispiel-Back-End veröffentlicht. Probieren Sie es einfach selbst aus und nehmen Sie an einer Umfrage zur Sitzungsverwaltung teil.