I have:

1. Several legacy SQL tables with custom user, roles/claims data
2. WinForms fat client in which user creation/changing belongs
3. Asp.net project which uses those tables to make cookie/jwt on login and to authorize some api methods
4. New asp.net web api services upcoming which still need to authorize users

So main problem is user data changing. User logins in web project, asp.net generate cookie/jwt based on current roles/claims which can be eventually used in authorization (without database call). But how can I actually knew if this data is still actual? How can I track moment, when it’s changed?

As far as I understand, basic flow of authentication/authorization if I use ASP.Net identity is:
User logins in system, system generates cookie/jwt with user info (roles and claims too)
This token is used in authorization. And as far as token is valid, we don’t make additional database calls. When I change user role through asp.net identity it invalidates token (?) and with next request cookie/jwt will be generated again based on actual data.

So I will be grateful if you share any thoughts about those topics. Especially:

1. Do I understand correctly basic flow, especially a part with minimizing database roundtrips and storing roles/claims inside token.
2. What is a preferable way of dealing with user data actualization across multiple systems
3. Is it actually bad to check user data on every request to authorize him? Or to load user into context with his roles/claims on every request? We talk about system with 1-3k users workload

What I thought about:

1. Simple solution is to check user data on authorization through database call. If api can be used only with some claim/role, we make database call and check that user has it. It works, but obviously it will scale poorly, especially because of many asynchronous calls from client.
2. Changing reevaluation settings of token. For example, change settings of cookie so it will reevaluates every minute. So even if change roles/claims, we don’t need to logout/login, after one minute we will regenerate token again with actual data. But with greater periods we will get more stale data.
3. Add some “stamp” columns to tables, which will be changed on update. In this case we can make database calls to check if any data has changed, and if so, we will reload all data to token. In this case we still need to make calls to database, but at least we will not load any data most of time.
4. Make separate ASP.NET authentication/authorization server with identity in which all user creation/changing functional will belong. And on each request we will contact our server, which will check if token is valid and so on. I’m not even sure if it should works like this or will it gain some potential scalabillity