Does the generated code cover authentication for SPA clients? Which part would need to be adapted?
Why is there a session token generated in the user codebase?
When using Plug.Conn.put_session/3, Phoenix already generates a cookie-session (it uses Phoenix.Token if Iām not wrong), where one can for example store the user ID. The cookie is signed and cannot be altered. The subsequent requests can retrieve the user ID from the cookie and user data can be fetched from db.
However, instead of storing just the user ID in the Phoenix token with put_session/3, the generator stores a token in the Phoenix token itself (and then retrieves user data from db based on the token). Isnāt that redundant? Why do we need to create a session token in the user codebase if put_session/3/get_session/2 handles that already?
Iāll start with these two questions first:) Thank you for any help.
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.
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.
Thanks for your response. Indexing by UUID-alike has to be generally more costly than by an int I believe, and then for retrieving user I either need two trips or a join. Two trips is a no go. Join is OK, surely āless badā of the two yet still not free. But yeah - Iād need to do some proper benchmarking to stop guessing and see what the difference actually is. Might in fact be that it is negligible even in large DB, high-traffic applications.
Not necessarily. PostgreSQL compiles the UUID to a simple byte array (128 bits / 16 bytes) and searches for that, and it is just 2x bigger than the normal numeric IDs (64 bits).
I doubt this will make a significant difference unless youāre doing 10k+ queries per second. And Iāve seen average tier Amazon RDS databases handle 50k+ reqs/sec easily (never going above 40% CPU).
Canāt claim it with 100% certainty, I simply looked at how PostgreSQL is doing things (a while ago) so IMO the abstraction layer is not important. Hope that I am not egregiously wrong.
There are two things about indexing. One is the lookup performance related to the index structure/column(s), another one is the index size and related resources usage. In small and madium-sized datasets this isnāt going to be of any issue on modern hardware. OTOH I relatively recently worked on a set of applications backed by large databases. When one gets into nine figure ranges of interrelated records things look different. We had to be really careful about how and by what we wanted to index things and what querries we wanted to execute Things that worked nice on a dev machine could easily spell a disaster on prod DB. Now, I agree that such apps may not be common. Itās simply that I am mentally still in that āhigh alertā mode. For the current Phoenix based project I donāt expect problems but I plan to do some benchmarking anyway
Are there any simple rules/parameters based on which I should invalidate a session token and force the user to log back in?
For example:
user agent changed: wonāt work for most apps because nowadays users access those from multiple devices;
ip changed: same problem as above;
location changed: requires a third-party allowing to resolve an ip to a location.
Correct me if Iām wrong but storing the session token in DB will not be useful until such automatic invalidation system is implemented. I donāt see any other way to invalidate a session tokens in DB.
(Not saying it shouldnāt be stored though, itās a must as the above system should be implemented some day).
Your first two points are exactly why you would want a session token instead of just an auth or bearer token. If the auth or bearer token were to get compromised, even if you forced logout for any connected sessions with that token (say they user logs out in one tab), the other device with that same auth/bearer token would immediately be re-authenticated because their token is still valid. By storing one token per āsessionā (connected user), you could individually control logging each tab/browser/device out.
I recently just ran into the same problem with a legacy app where they only used auth tokens and did not have the tokens stored in the db. As a result, if you asked the auth service if the token was valid, it would always be. Logging out was only managed by deleting the token from the session so the browser no longer knew what it was. However this means that if another browser is using the same token, they donāt get logged out when you log out of your tab. Having a unique token per connection gives you finer control of which sessions get terminated and when. And there is no more load on the system because you still have to look up at least one token anyhow.
Additionally, you could now display for the user all of the sessions using their account and allow them to invalidate any they donāt think are legitimate. Then the compromised session user would need to re-authenticate and if all they knew was that session token, they would not be able to unless they knew the username/password.
Iām actually in the process of adding the exact mechanism phx_gen_auth uses in my legacy app right now for these very reasons.
