- Let's make the authentication system so the user can only login in one device at time, because this is more secure.
- You know that this will be a general-public application, right?
- Yeah!
- Sou you want to "punish" users with a logoff on the other device when he tries to login in a new one?
- Yeah!
- But before you said we will use Json Web Token to make the backend stateless.
- Yeah!
- And how will we check if the token is the last one generated?
- We will store the last generated token for this user on a table in our DB.
- So... you are basically describing the old authentication model, with session tokens stored on the backend and communicating them via cookies.
- Yeah, but the token will be sent on the Header, not on cookies
- Okay, so why will we use Json Web Token to do this in the first place?
- Because this is how they're doing now, and this will make the backend stateless.

A moment of silence, please.

How do you plan on dealing with compromised tokens?

@ymas usually you put an expiration date on the token and create a blacklist to the compromised ones. This way you can verify the token against this list, and to avoid the blacklist to grow indefinitely you only need to keep the blacklisted tokens until their expiration date, when they will become invalid from that moment forward.

Where are you going to store the blacklist?

@ymas On the database, but at least the user can login in multiple devices.

(but the rant is more about the use of JWT to accomplish the old model of authentication)

@tokenguy I understand the point of your post, I sympathise with you. How are you planning on dealing with introspection?

@ymas At least on the proposed application, the backends will have access to the authentication service, and they will be allowed to request information using Basic Authenatication AND the communication between them will occur inside a VPC. Since the JWT contains his own signature, to every request we could check if the signature is valid, if it's not expired and if it's not on the blacklist. The information on the token's payload could be minimal, like an user_id that stores an uuid (or in the worst case, the actual numeric id of the user on Users table)

@LicensedCrime @J-2FA

I've been developing my own authentication system, following the best security practices and most, if not all, of them blame the unique session approach...

My authentication system, in a simplified explanation, have the following concepts:

Activity - object that represents user actions (login for example), containing a random id, a description, IP address and some other metadata.

Authenticator - object that represents the user session, containing a random id, a user and an activity)

Given a USER, then I'm able to find his last login ACTIVITIES and when either the user or me (as the system) wants to logout any or all sessions (AUTHENTICATORS), then we just need to specify which one we want.

The authenticator is cached (encrypted at rest) on Redis for the expiration time which is very short and every so often the user needs to renew it's session. The JWT token holds the authenticator id, activity id and user id.

Stateful sessions may be and are good if done properly.