Tokens are created with an identifier, creation time, and expiry time. They are signed. For web connections I use a renewal token with a long expiry (in the

Tokens are created with an identifier, creation time, and expiry time. They are signed. For web connections I use a renewal token with a long expiry (in the weeks) that is used to ensure we always have a fresh active token (in the hours). You can't get an active token with a refresh token that has a creation time less than a timestamp stored with the login details. This allows revoking within a few hours, which is good enough for the vast majority of cases. I also maintain a pushable blacklist for emergencies - good UX for this is have the revoke button lead to a "X has successfully been logged out, this may take a few hours to affect all of our services. If it is important that they are logged out immediately click here <Force Immediate Logout>". For mobile devices which need to limit requests to the server I allow passing a refresh token to most of the services, which will validate it via the server and return an active token with the response. This works well for the applications I use it in, because I can do instant revokes, but gradual revokes are business case acceptable. Having a token does not allow you to purchase or permanently delete anything. "Super Admin" actions are done with a different system (that only appears integrated to the end user, different DB logins and everything) that requires password validation anyway. It is not suitable for every application, but it does allow me to operate without inter-service communication for the vast majority of the time.