Authentication

01In a nutshell #sec_ae957ae4

REVIEWIT is its own authentication authority: the client retains its identity provider, and the product reserves the right to decide what it accepts as proof of identity—and with what level of assurance.

02The problem #sec_a55cce9c

A recertification tool asserts, campaign after campaign, that such a person has decided such a thing. All the probative value therefore rests on a question prior to everything else:

What guarantees that it was really her?

Three difficulties accumulate, and they are not of the same nature.

The client already has its identity provider. It will not change it for a tool, and it is out of the question to ask it to create additional passwords. A company directory, a cloud provider, sometimes several depending on the entities—the tool must rely on them, not replace them.

Relying on a single provider locks the product in. Software that can only authenticate against a single ecosystem is unusable for those who are not part of it, and becomes hostage to the provider's evolutions.

Not all authentications are equal. Opening a reviewer's work queue and modifying the governance parameters of an entity should not require the same proof. It is also necessary to know, at the time of the access decision, how the person authenticated—information that applications almost never have.

03The approach #sec_d821c25a

The product delegates the verification of identity, never the decision of what it accepts.

REVIEWIT introduces an internal authentication authority. Applications no longer talk to an identity provider: they talk to this authority, in a standard language. The authority, in turn, takes care of verifying the identity with the client's provider, whatever it may be.

The gain is twofold. The client keeps its directory, its rules, its authentication policy. And the product gains a unique place to reason about what it accepts—instead of leaving it to four applications that would each do it in their own way.

Six principles structure this choice. They are what make the difference between "it works" and "it holds up to an audit."

1. The proof is the evidence, never the request

This is the most important principle, and the most counterintuitive.

An application can ask the identity provider for strong authentication. But this request is only a request: depending on the provider, its configuration, the state of the session or the policy in effect, it may be partially honored, ignored, or silently bypassed.

REVIEWIT therefore never relies on what it has requested. It verifies what comes back, and if the expected proof is not there, access is denied. Asking is an effort of goodwill; verifying is the guarantee.

This is what separates a displayed security policy from an effective security policy.

2. The level of assurance, not the mechanism

Applications never reason about "has the person used such a device." They reason about an ordered level of assurance:

A screen requires a minimum level; the mechanism that produced it does not matter. The advantage is durable: when a new means of authentication appears, it is enough to know at what level it corresponds—no application needs to be modified.

The product also keeps the time of authentication, which allows it to require a recent authentication for a sensitive action, and not just a valid authentication. This information is never reconstructed by approximation: if it is missing, the freshness rule fails rather than letting it pass.

3. Never automatic matching by email address

When an unknown identity presents itself, the temptation is to attach it to an existing account with the same address. REVIEWIT never does this.

The email address is not a proof of identity: it is declarative, reassignable, and falsifiable with a poorly configured provider. Automatic matching on this criterion is a classic vector for account takeover—it is enough to have an identity issued with the correct address to inherit someone else's rights.

The link between an external identity and a REVIEWIT account is therefore established on a stable triplet—the provider, the issuer, the subject identifier—and a match between several providers is a controlled and explicit flow, never a deduction.

4. The REVIEWIT account is the session authority

A successful authentication with the client's provider is not enough to open a session.

The product keeps its own account registry, and this registry decides: an account deactivated on the REVIEWIT side is denied access even if the identity provider has just successfully authenticated it. The two life cycles are separate—revoking an identity link is not deactivating an account, and vice versa.

This verification is replayed at each access issuance, including during the silent reconnections allowed by the single session. This is precisely the case where one might think there is "nothing to reverify"—and it is the case where a deactivation would otherwise remain ineffective for hours.

5. Identity and context are not confused

The authentication authority establishes who you are. It never decides what you are entitled to, or to which subscription or workspace you belong.

When a context is transmitted, it is as a signed hint—useful to avoid the user having to reselect their scope—and never as proof of membership. The application systematically reverifies the rights as if this hint did not exist.

Confusing the two is the error that produces the most discreet privilege escalations: a token that asserts a scope always ends up being believed.

6. Secrets are not in the database

The database contains the reference of a secret, never its value. Secrets live in a dedicated store, with a double-version rotation mechanism: the new secret becomes active while the old one remains accepted during the switchover, then is revoked.

The same reasoning applies to keys: those that sign tokens intended for humans are distinct from those intended for machines, with explicit issuers and recipients. A token issued for an application is never acceptable where another is expected—the mechanisms are shared, never the secrets.

04Two authorities, deliberately separated #sec_dd4e68e8

These two worlds have different threats, life cycles, and requirements. Making them coexist in the same authority would sooner or later lead to a token designed for one being accepted by the other. See the [API dossier](REVIEWIT_Dossier_API_v1.0.md).

05The client's identity provider #sec_9c97a8ca

Each subscription declares its identity provider(s). The routing is done on the domain of the professional address: the user enters their address, and they are sent to the provider that concerns them.

Providers compliant with modern standards are natively supported, which covers most of the fleet, including self-hosted company directories in their recent versions. Older protocols are handled by adapter, in a second step.

One design point deserves to be noted: user connection and data collection are two distinct paths. The permissions the product needs to inventory a client's resources never transit through the connection path. A user who connects grants nothing other than their identity—and a modification of the collection configuration cannot break authentication.

06Backup accesses #sec_5e779c5b

The product provides backup accounts, in case the client's identity provider is unavailable.

Two safeguards: these accounts are explicitly designated, one by one—there is no rule of the type "all administrators can connect differently"—and their use is subject to enhanced recording in the [audit trail](REVIEWIT_Dossier_PisteAudit_v1.0.md).

A backup access is an assumed exception, not a permanent back door.

07A deliberate choice: clean-slate replacement #sec_50dd8f34

The old authentication system is not migrated, it is replaced. No dual path, no period where both coexist.

The reason is security, not convenience. Maintaining two authentication paths means maintaining two attack surfaces, two sets of secrets, and the permanent obligation to verify that the weaker of the two cannot be used to bypass the other. The old application registrations are decommissioned and their secrets revoked.

It's the same reasoning as for the [audit trail](REVIEWIT_Dossier_PisteAudit_v1.0.md): better a short and clear foundation than a long one about which nothing can be affirmed.

08What the product does not do #sec_c39b58a6

• It does not manage passwords. REVIEWIT does not store any, does not verify any, and does not expire any. This is the job of the client's identity provider.
• It does not implement its own multi-factor authentication. The strengthening of authentication relies on the client's devices. What the product provides is the ability to require and verify a given level — not to provide it.
• It does not decide on rights. Authentication establishes identity; authorizations are carried by the workspace and the subscription.
• It does not trust a declaration. Neither the email address, nor an announced context, nor a request for strong authentication is proof.

09To remember #sec_5948ea3f

Authentication is the foundation on which everything else rests: without it, "Mary certified this access on March 14" is an unverifiable statement.

REVIEWIT relies on the identity that the client already controls, but keeps control over what it accepts. It verifies proofs instead of relying on requests, reasons in levels of assurance rather than mechanisms, refuses the convenient reconciliations that make for takeovers, and reserves the final say on the opening of a session.

This is what allows us to affirm not only that a decision has been made, but by whom, and with what degree of certainty.