"An employee who resigned last month could still view sensitive data from their account"—chilling reports like this occasionally arise in custom systems handling sensitive information. The cause usually stems from authorization (verifying whether a person is permitted to perform a given action) being conducted solely at the moment of login. Once confirmed as "this user is an administrator" at login, permissions are never rechecked until the session expires. Consequently, even if privileges are revoked or offboarding is processed after login, actions still succeed in already-open tabs or active sessions. While authentication (verifying identity) is solid, authorization is treated as a "one-time check at the door"—a hole frequently overlooked in sensitive systems.
The concept that rectifies this "one-time check at the door" is Continuous Authorization. Designing Continuous Authorization for Sensitive Cloud Systems (InfoQ), published by InfoQ in June 2026, details architectures for continuously validating authorization on every operation within sensitive cloud systems. This article outlines how to shift authorization from "once at the entrance" to "on every action" when building or taking over systems handling sensitive data in custom development.
Why "login-time-only authorization" becomes a loophole
Verifying permissions at login and baking the result into the session for reuse—this architecture is easy to implement and computationally lightweight. The issue is that in reality, permissions change mid-session.
First, permission changes do not take effect immediately. Even if an administrator is demoted to a general user or disabled upon resignation, already-issued sessions retain the "permissions from the time of login." Changes are reflected only when the user logs in again—meaning only after they choose to re-authenticate.
Second, screens left open for long periods become hazardous. Enterprise business applications are frequently left open unattended. If fixed to login-time permissions, actions continue to succeed from those open screens even if organizational restructuring or employee offboarding takes place in the interim.
Third, context is entirely ignored. A login-time evaluation only asks, "Is this person an administrator?" For sensitive data, however, context—such as "are they accessing from an unusual location?" or "are they downloading large volumes of data during off-hours?"—should ideally factor into authorization decisions. A single check at the entrance cannot detect anomalies that arise mid-session.
The risk of baking permissions into tokens and passing them around overlaps with session management design. Questions regarding where authentication credentials should be retained and how they should be revoked tie directly into issues explored in our article on JWTs and sessions.
Continuous authorization basics: shifting toward "verifying on every action"
The concept of continuous authorization is simple: re-verify permissions at the time of each critical action. Rather than continuing to trust login-time evaluations, the system queries the latest permission state right before an operation: "Can this person do this right now?"
従来（入口で一度きり）:
ログイン → 権限を確認 → セッションに焼き付け
以降の操作 → セッションの権限を信頼（再確認しない）
継続的認可:
ログイン → 認証（本人確認）
重要な操作のたびに → その時点の権限を都度確認
（無効化されていれば即拒否）The crux of implementation is centralizing authorization decisions into a single "policy enforcement point" rather than scattering them across the application. If individual screens determine on their own that "this user is an admin, so it's fine," permission logic ends up fragmented throughout the codebase, leading to vulnerabilities where a screen forgets to re-evaluate. Centralizing checks ensures a uniform policy: "always route through this point before critical operations to verify current permissions."
| Dimension | One-time check at login | Continuous authorization |
|---|---|---|
| Permission update reflection | Delayed until next login | Reflected immediately on the next action |
| Locking out former employees | Access persists until re-login | Can be denied immediately |
| Evaluation point | Tends to scatter across screens | Centralized in one place |
| Contextual awareness | Not possible | Access conditions can inform decisions |
It is important to note that "checking every time" does not mean "running a heavy remote query every time". Querying the core permission infrastructure on every single operation introduces latency, so in practice, architectures strike a balance between performance and security—such as caching decisions with short TTLs or strictly verifying only high-stakes operations. There is no need to treat everything as top priority; applying differentiated scrutiny to sensitive actions is the pragmatic choice.
Pitfalls when adopting it in client web development
In an HR custom system whose security remediation we took over (company name withheld), the exact scenario described at the outset had occurred. Although HR had processed the offboarding of former employees, the system had baked permissions into sessions at login, leaving data accessible for a period from screens left open by former staff. Fortunately, no actual harm occurred, but it had to be resolved before being flagged in an audit.
Rather than overhauling all functionality at once, we subjected only operations touching sensitive data to continuous authorization. We established a checkpoint directly preceding operations that handle sensitive information, such as viewing or editing, to re-verify permissions on the spot, rejecting disabled accounts immediately. By narrowing the scope to high-risk actions without over-restricting ordinary page transitions, we locked out former employees instantly while minimizing performance overhead. All we did was move the evaluation from a one-time check at the entrance to a checkpoint directly preceding sensitive actions.
The most impactful lesson from this remediation was making "deny by default unless there is explicit justification for access" the rule. If the system defaults to "allow for now" when an authorization query returns an ambiguous result, a temporary outage in the permission infrastructure could mistakenly grant administrator-level access to everyone. Conversely, defaulting to "deny without proof" ensures that, at worst, the system halts with an error rather than erring toward data leakage. The risks of missing permission checks at API boundaries are demonstrated by cases in our article on API gateway authorization bypasses, illustrating how easily perimeter-only checks can fail.
Another pitfall is confusing this with strengthening authentication. Continuous authorization is a mechanism for validating "whether this person can do this," which serves a different purpose from strengthening identity verification via passkeys. The two complement each other: pairing hardened passkey authentication with continuous authorization checks yields optimal results. For authentication strategies, refer to our article on passkey migration.
Where to begin
If permissions in your sensitive data systems are frozen at login, shifting your "most critical operations" to continuous authorization first is well worth the investment. There is no need to rebuild every feature all at once.
As a first step, identify the single operation in your system where "a leak would be most catastrophic," and place a checkpoint immediately before it to verify current permissions on each request. Then, configure that evaluation to default to "deny without explicit justification." This alone closes the worst loophole: allowing former or demoted employees to continue performing sensitive operations from open screens. By expanding the scope of target operations incrementally while verifying performance impact, overhead remains controlled.
If you are concerned about active accounts from former employees, frustrated that permission changes do not take effect immediately, or worried that sensitive data systems rely on a single check at login, please reach out via GleamHub's contact page. We will review your current authorization architecture and work alongside you to design a phased transition to continuous authorization for sensitive operations, balancing security with performance.
