Allow for user tokens to be invalidated

[stridger]

Currently user tokens are not stored in the DB or anywhere and thus cannot be invalidated. This presents a security issue if tokens get leaked and it was possible to invalidate them before 5.3.

Ideally the system would know about what tokens exist and would allow to invalidate them.

My personal context is that we use Traccar for a school bus system where parents track the buses. So the token URLs are shared with all parents and updated/invalidated on a yearly basis. I can work with the new system for now, but if the tokens ever leaked I would probably have to hack the system to delete and recreate user accounts etc.

Also see related discussion on https://www.traccar.org/forums/topic/how-to-invalidate-access-token/ .

[tananaev]

I think the more modern approach to tokens is to have them as short lived instead of long lived tokens with an option to invalidate.

[stridger]

I think the more modern approach to tokens is to have them as short lived instead of long lived tokens with an option to invalidate.

For tokens which are used in Software that is definitely true. I have however described my context above, where I simply want people to be able to login with a URL without a shared username/password etc. And for that it is important to be able to invalidate tokens when necessary.

[tananaev]

How many times have you done it so far? What are the stats?

[stridger]

So far we have been on 5.2 precisely because I was waiting for the new token system to mature. We have needed to reset the tokens on at least 2 occasions in that, not because tokens leaked but because the audience changed due to unforeseen circumstances.

But I cannot hold off the upgrade any longer, so I am upgrading to 5.12, but can foresee problems with not being able to invalidate user tokens.

[tananaev]

Can you elaborate on the audience change? Wouldn't that just be new user accounts naturally? I don't think I fully understand the context. And 2 occasions in what period of time?

[stridger]

So the accounts I have are shared amongst many people (up to 60 or so) that monitor the buses, but they can only monitor the bus their kid is on. When for example bus routes have to change, which occasionally happens, then the audience changes and so I reissue the tokens so that people can only see the buses they should have a view of. Routes rarely change and this was 2 occasions within 3 years, but the general point is that not being able to invalidate long lasting tokens can be a problem.

[tananaev]

It sounds to me that you're not using the system as intended. You should have an account for each user and then you can just link/unlink devices as needed.

[stridger]

Well issuing and managing 300 user accounts is not part of my scope as a volunteer and also people would hate having to login just to see where the bus is each day :-)

The point is that the system is perfectly usable for my scenario and has been working perfectly for 4 years (thank you for creating a system that we could use!).

The wider point is that revoking user tokens seems to be something that ought to be possible for any use case.

[tananaev]

I agree in general, but to prioritize this we would need a stronger case for it. For now we can keep this open to gauge the interest.

[lightseeker34]

Of all the things that I'm looking for, this is definitely a huge priority for me also. Would love a token management feature in the future. Thanks.