Here’s what I would do, at least in a corporate setting:   I would use LDAP (nee OpenDirectory) as the basis of both authentication and authorization.   This is a well-known and of course well-supported source that can be used throughout a company.   The department responsible for security can click a button to update a record, knowing that all of the applications, badge-readers, and what not throughout the company will instantly and uniformly respect it.   This can be done on the web-server level, making the entire app inaccessible to those not authorized to use it.

LDAP (or Kerberos) is used both for authentication and authorization.   The company should set a standard for how it wants to consistently manage these two concerns, and every securable thing in the company including this application should then follow suit.   If you want to know whether a user can do something, you query LDAP to find out.   You do this each time, so that changes take effect immediately.

At the very least, your “home grown” system needs an Account Disabled boolean flag.   If the account is disabled, you can’t log in or stay logged in.   If the (internal) user-ID is part of the HTTP sessions table, all existing sessions associated with the user can be deleted.   Presto, he is no longer logged-in and cannot log in again.