Client-side sessions are nice because they are simple and you don't need a backend in your server. But they have cons too: - If a user changes his password, o

Client-side sessions are nice because they are simple and you don't need a backend in your server. But they have cons too: - If a user changes his password, other sessions will keep active until they expire. This is a problem when (and not if) an account gets compromised. You can fix this easily, for example, including a token for each user that changes when changing the password, but then it defeats the point of client-side: you have to store the last token somewhere in your server. - With the default implementation of Flask, if your secret key somehow leaks, apart of the obvious problem, anybody could execute arbitrary code in your server. You can fix this easily and without any serious consequences (apart from kicking out all your already logged users) by using JSON to serialize the cookies instead of Pickle: https://gist.github.com/2501926 https://gist.github.com/2501926 - You are limited to 4 KB of data. In a server-side solution the user has only a session ID that gets associated to all the data you want in your database. Related discussion: http://flask.pocoo.org/mailinglist/archive/2011/8/15/security-of-secure-sessions/ http://flask.pocoo.org/mailinglist/archive/2011/8/15/securit...