In der Security Demopalooza adressiere ich #Security Themen, die in meiner täglichen Arbeit oft/öfter gefragt werden. Für eine Liste der bisher behandelten Themen besuche einfach die Übersichtsseite der Security Demopalooza.
Bevor ich in das eigentliche Thema einsteige ein kurzer Exkurs in das Thema „Token“: [Wer tiefer einsteigen möchte, der sollte sich u.a. hier oder hier einlesen.]
Es gibt mehrere Arten von Token, wichtig insb: 1. Access Token, 2. Refresh Token. Vereinfacht ausgesprochen ist das Access Token das Ticket zum Konzert und das Refresh Token der Stempel auf der Hand für den Wiedereintritt (streng genommen der Stempel um ein neues Ticket für den Eintritt zu bekommen).
Typischerweise ist dabei der Zutritt über das Access Token streng zeitlich limitiert (i.d.R. 1h) und damit muss ein User sich jede Stunde sowohl ein neues Access als auch ein neues Refresh Token erfragen (und ausgestellt bekommen).
Sicherer wäre es, wenn die Zeitspanne kürzer wäre, aber damit ginge gleichzeitig eine höhere Belastung der Infrastruktur (und ggf. des Users) einher, daher ist 1h ein brauchbarer Mittelweg.
Außerdem gibt es noch die sog. ID Token, diese sind vergleichbar mit Access Token, nur dass darüber keine Berechtigungen/Zugriffsidentität vergeben werden, sondern die Useridentität transportiert wird. Und es gibt noch (non-)persistent SSO Token, die ähnlich zu den Refresh Token sind, jedoch keiner Applikation eindeutig zugewiesen sind.
Jetzt ist es so, dass das Konzept der Tokens nicht jedem User klar ist (muss auch gar nicht, bzw. sollte auch gar nicht), sich aber trotzdem die Tokens für User in gewissen Formen materialisieren, z.B. in der folgenden UI:
D.h. durch die Klicks auf „Don’t show this again“ und „yes|no“ beeinflusst der User ohne es zu wissen das Verhalten/Gültigkeitsdauer der Token.
Eine Auswahl einem User zu überlassen, der im Zweifel gar nicht weiß, was seine Aktion für Konsequenzen hat, halte ich persönlich für falsch und daher sollte man ihm diese Entscheidung abnehmen.
Hierzu gab es lange Zeit eine Preview für das Managen von Tokenlifetimes – diese Preview wird allerdings [sofern überhaupt noch vereinzelt in den Tenants zu sehen] im September 2019 abgeschaltet.
Wir haben uns dazu entschlossen das Thema besser über Conditional Access zu steuern, welches sich für die Session Verwaltung zum Zeitpunkt dieses Posts [08.07.2019] in public preview befindet:
D.h., dass die User auch gar nicht mehr gefragt werden (müssen), ob sie angemeldet bleiben wollen.
Für die Admins habe ich in meinen Testtenants entsprechend die Gültigkeit auf 10h gesetzt und die Persistenz nicht konfiguriert, für die User auf 30d und die Persistenz aktiviert.
Noch eine Anmerkung: wenn ein Useraccount gelöscht/disabled wird, dann werden automtisch vom System die Sessions/Tokens für ungültig erklärt und er verliert sofort den Zugriff auf die Systeme.