I am in the process of designing my own auth system, and as a result I’ve had a close look at phx.gen.auth to get a feel for best practices.

Most of the design choices are quite straightforward and clear, which is great, but one thing I’ve been wondering about is the choice to use a separate remember_me_cookie to store the user_token outside the Plug session.

For anyone who is unfamiliar, it works like this:

1. When a user logs in, a user_token (a long random string) is generated via the Accounts context
2. Assuming “Remember me” is checked, the token is stored in a remember_me_cookie named app_user_remember_me
3. The token is then copied from the remember_me_cookie into a user_token value stored in the Plug session
4. That user_token value in the Plug session is used to authenticate and store the current_user via the Plug/LiveView pipelines
5. Since the Plug session is, by default, stored as a session cookie (noobs beware: this is a completely different meaning of the word session), it will be lost whenever the browser feels like it (probably on restart), at which point we jump to Step 3

What I’m wondering here is why bother with the remember_me_cookie shuffle instead of just storing the token in a cookie directly? A good chunk of the code in auth.ex is dedicated to copying the token from the cookie to the session.

Also, storing the cookie in the session then necessitates clearing the session on login to prevent fixation attacks (as helpfully explained in a comment), but if the token was just stored in its own cookie this would not be necessary. Though, from what I can tell, it’s actually not necessary anyway by default as the default session implementation does not actually have a session id (it just encodes/signs the session data directly into the cookie), meaning a fixation attack would not apply. But I presume it was written this way in case users swap in their own Plug session backend (i.e. store it in Postgres), at which point fixation attacks would apply, and it’s better to handle that from the start.

Anyway, I suspect this separate cookie business is done just because it’s idiomatic to store the token in the session, but I figured I’d inquire in case there’s something I’m missing. I suppose it also handles the case of the user unchecking “Remember me” nicely, but you could just set the expiry of the cookie instead so I don’t think that’s the reason.