Why does `phx_gen_auth` create a session token? (and other questions)

Only with a session token in the db you can invalidate a single compromised session. For stateless session management a compromised session would mean you need to either change your signing secret — and therefore invalidate all your active sessions — or wait for the compromised session to timeout potentially doing more damage in the meantime.

You could remove access at other level, e.g. deactivate the account for the compromised session, but this would lock the account even for legitimate usage on other sessions.

Could you please elaborate a bit, preferably with example(s)? What specific scenarios does this help addressing? The one I can think of is when a user left without logging out, leaving open session behind for someone else to take over. Or am I on the wrong track?

Exactly. Someone could easily expand the current feature set to do something like Gmail that lists all of your open sessions with the location and device that started them. It is can also be good even for history itself and keeping track of devices.

In a less common but not impossible case, maybe you gave your old computer to a relative or friend but didn’t format the machine and forgot to log out of an important site. As technical users this type of thing seems nearly impossible to happen but not everyone is hyper diligent with their privacy.

The above case is also IMO a good example of why adding an “active” attribute to control access isn’t enough because as LostKobrakai stated, that would also lock out the real account owner.

As soon as whatever secret you supply to the user leaves your server it‘s no longer in your control. There are tech. measures like https or browser sandboxing to prevent access to that secret by third parties, but all those might fail, have bugs or whatnot. If they do a third party might get to know the secret knowingly or unknowingly to the actual user. Therefore you should have control over sessions on the server side, to have counter measurements for those cases. The longer a secret is valid on it‘s own, the more important this becomes.

When the generator ships with 1.6 and has docs, I wonder if it’s worth writing a couple of paragraphs around that and also giving a number of real life examples where an “active” field can’t be used as a replacement for session based access.

For something as important as this, the more explicit you are the better, especially since if you don’t spend a lot of time thinking this through it could be easy to talk yourself into thinking an active field could do the job so you may decide to abort the idea of saving it server side.

Edit: To add another potential real life use case, maybe you accidentally forgot your tablet somewhere and you’re not in a position to immediately get it back (left it on a train, etc.) but you want to sign yourself out of a bunch of sites to avoid a potential future headache.

Docs have been updated here: Add more docs to phx.gen.auth tokens by josevalim · Pull Request #4405 · phoenixframework/phoenix · GitHub

When people ask why I like Elixir and Phoenix I point to stuff like this. The team, Chris and Jose really care about dev ux and happiness.

Thank you guys for the quick and highly constructive response! I could imagine and understand what the advantages are from the first @LostKobrakai response. Still I find the extended, more explicit documentation a highly valuable outcome of the discussion.

I came to this thread because I compared my “home-baked” approach that I’ve been using in multiple projects and carried it over from Rails to Phoenix. The main difference was exactly this not so tiny detail. In my old approach, I also removed the “remember me” part in some projects and used encrypted session with maximal one day validity time (in most projects a shorter one - important for financial stuff f. e.) and found it “good enough”. Now I am still a little concerned about potential performance implications of using DB stored tokens approach in high-traffic situations where every DB roundtrip count. Please correct me if I have no reasons to be

Honestly, I doubt this is a concern. You need to lookup the user in the first place. The difference is that, instead of doing so by ID, we are doing it by token. Which is also indexed and it would not be much different from a UUID lookup. The number of round trips is the same.