Currently, when Kafka client establishes an authenticated session with a Kafka broker, after the successful token validation, there are no further considerations about the validity of the access token during the session. One of the features of the central security servers is to be able to terminate users' sessions on demand. For example, if user is blocked, or client is blocked then, ideally, that would mean that any ongoing session by that user or client gets invalidated and closed as well. One way this is achieved by OAuth 2 implementations is by using short-lived access tokens which have to be refreshed quite often (between one and several minutes, for example). That works for web based sessions because every request during a session is accompanied by a token, and validated. In Kafka, only session initiation involves token exchange and validation. Once authenticated, the session is valid regardless of any token revocation that might occur at authorization server. Since Kafka application sessions may be very long-lived a lot of time may pass between client or user being cancelled on authorization server, and that resulting in complete access revocation of that user or client on Kafka resources.