Traditionally this is solved with short lived sessions, you can expire the cookie and your token if you use phoenix tokens. Then you also avoid having to store anything on the server other then having to validate the token. Obviously you loose the ability to query your database for active tokens. But you could use Phoenix presence for that.
Alternative you would have to use the database as the source of truth.
As everything in engineering, we’re working with trade-offs.
How would a token in a cookie be any more revokable than one passed via other means?
AFAIK, sessions with cookies specifically — can be revoked at any time (stateful auth), while tokens are always valid until expired (stateless auth) — thus short lifetime is desired for tokens as they can’t be revoked by other means. This is what I learned in a day of researching authentication (with which I have little experience)
Actually I want to store session on the server and try to avoid tokens, because of this article: Stop using JWT for sessions - joepie91's Ramblings (not sure if it apply for any token-based authentication and not only JWT, but AFAIU Phoenix token is somewhat similar to JWT because it is stateless and valid no matter what, until expired, which is similar to what is described in the article)
I want to avoid using tokens altogether, so cookie will contain session ID for DB-stored session
The divide between expirable stateful (as in: stored on the server side) sessions and stateless (as in: client held, only) tokens is not completely cut and dry in that one can be revoked at any time and the other only on expiry.
Assuming one is fetching a stateful user record when receiving a token, it is easy enough to include a “oldest accepted token timestamp” in that record (db row in a users table, e.g.) and compare that timestamp with the issuing time on the token, refusing any that were issued before the oldest accepted timestamp. With a secure token, this allows one to sign out of all sessions by setting the oldest accepted token timestamp to the current timestamp … which allows a form of revocation through denial of acceptance.
What is a lot harder to achieve it just denying one specific login without having access to it (e.g. “Invalidate the session on my phone which I lost”). Stateful sessions do have an advantage here.
There’s also a topic in here somewhere about separating authentication and authorization, which can have different requirements and approaches.
© Copyright Elixir Forum | Terms | Privacy & Cookies
