> Fine, revoke the master token
This is exactly the ability which JWT lacks.
You can, of course, combine a session ID (checked against a DB) with a short-lived token (stateless, with expiration time encoded). This will allow to only check the session against a DB if, say, more than 30 seconds has passed since the previous check. It helps with spiky traffic, and still allows to invalidate a session soon enough for practical reasons.
And this reduces complexity of all backend systems, as they only have to deal with one mechanism for authentication and authorization.
Re:Stop using JWT for sessions (2016)
by martin-adams on Thursday November 01, 2018 @11:09AM
(#18354619)
>> Fine, revoke the master token on the authentication server and after 5 minutes at the latest
That might be fine for a lot of use cases. But anything that can steal money using that token and 5 minutes is a very long time indeed.
Re:Stop using JWT for sessions (2016)
by mschuster91 on Thursday November 01, 2018 @04:00PM
(#18357834)
But anything that can steal money using that token and 5 minutes is a very long time indeed.
User gets banned or privileges revoked? Fine, revoke the master token on the authentication server and after 5 minutes at the latest, the user is locked out as he cannot get new valid short-lived tokens.
Sessions aren't difficult - as long as you stick to one language and environment (e.g. PHP). But as soon as you throw in for example Java to communicate with a SAP backend (as an online-shop system might need to), nodejs for a "support/sales chat" system and whatever, a JWT scheme is easier to implement.