I revoked their access but they are still inside: a session is not the same as a permission

You removed a user's permission. Maybe you disabled the account entirely. Then you notice that person can still do things.

Nothing is broken. Logging in and being authorised are two separate moments, and there is a gap between them.

Login happens once, permission is asked every time

When you log in, the system hands you a ticket. The ticket says: this person proved who they are, and this ticket is valid until such and such a time.

Permission is a separate question, asked again on every request. But in practice many systems take a copy of the permission map at login time, for speed, and use that copy for a while.

Two lags come out of this.

The first: when you remove a permission, an open session may keep carrying that copy. The change only reaches it when the session renews.

The second, and the more important one: deleting or disabling the user does not tear up the ticket they are holding. The ticket is self-contained and stays valid until it expires.

The rule: revoking access is not ending a session

These are two separate actions, and doing only the first leaves a window open behind you.

The window is not infinite; a ticket is not valid for a day. But it is not zero either, and in an urgent situation "it will close shortly" is not a good enough answer.

When someone leaves, or a password is suspect

Do three things, in order.

Remove the permission. Disable the account too if that is warranted.

Change the password. This closes the route to getting a fresh ticket to replace the one they hold. Removing a permission alone does not do that.

Remove the access tokens separately. This is the most commonly skipped step. A token is not a session: it does not expire on its own, it lives until you delete it. Changing a user's password does not invalidate their tokens. When you remove a user, check separately what became of their tokens.

And let us close one misconception: two-factor authentication does not help you here. It guards the moment of login. It has nothing to say about a session that is already open.

The other direction: why do I keep getting logged out

This is the other face of the same mechanism.

The ticket has a limited lifetime, and the interface renews it regularly while you are on the tab. Close the tab and come back hours later and no renewal happened, the ticket is dead, and you are asked to log in again. That is not a fault.

The second, less known cause is more interesting: the machine's clock. A ticket carries a timestamp. If the server's clock drifts, a ticket that was just issued can look as though it comes from the future or has long expired. The symptom is confusing: the password is right, the login seems to be accepted, and the session drops immediately after. Looking for a clock problem on the identity side does not occur to anyone, but look.

What Atlas does

In Atlas the cookie that goes to the browser is not the real ticket. The browser carries only a meaningless random identifier; the actual ticket stays on the server.

The difference is concrete: even if a browser flaw reads the cookie, it does not come away with the ticket itself, so it cannot carry it somewhere else and use it there. The only thing it can do is act from that browser while that session lives. That is not zero risk, but it narrows the scope of the threat.

Open sessions are written to disk, so nobody is thrown out when the product updates. The write is deliberately done in a single step: had the file been left half written, then even though the reading side tolerates it, every open session would have dropped.

What is really worth telling is a flaw found here by measuring.

Expired session records were being cleaned from memory only, not from the file. A live machine was checked: five expired records were sitting in the file, each with a ticket inside. They would have stayed there until the next login, because nothing else ever wrote that file.

The code's intent was already not to keep them. The only thing missing was the write step.

The lesson holds for anyone writing security code: forgetting has two places. Something removed from memory is not removed from disk, and of the two, the one on disk always lives longer. When you decide something must not be kept, the second question is always the same: where is it kept?