L'authentification

01En une phrase #sec_ae957ae4

REVIEWIT est sa propre autorité d'authentification : le client conserve son fournisseur d'identité, et le produit se réserve de décider ce qu'il accepte comme preuve d'identité — et avec quel niveau d'assurance.

02Le problème #sec_a55cce9c

Un outil de recertification affirme, campagne après campagne, que telle personne a décidé telle chose. Toute la valeur probante repose donc sur une question antérieure à tout le reste :

Qu'est-ce qui garantit que c'était bien elle ?

Trois difficultés se cumulent, et elles ne sont pas de même nature.

Le client a déjà son fournisseur d'identité. Il n'en changera pas pour un outil, et il est hors de question de lui demander de créer des mots de passe supplémentaires. Un annuaire d'entreprise, un fournisseur cloud, parfois plusieurs selon les entités — l'outil doit s'y adosser, pas s'y substituer.

S'adosser à un fournisseur unique enferme le produit. Un logiciel qui ne sait s'authentifier que contre un seul écosystème est inutilisable chez qui n'en fait pas partie, et devient l'otage des évolutions de ce fournisseur.

Toutes les authentifications ne se valent pas. Ouvrir la file de travail d'un reviewer et modifier les paramètres de gouvernance d'une entité ne devraient pas exiger la même preuve. Encore faut-il savoir, au moment de la décision d'accès, comment la personne s'est authentifiée — information que les applications ne possèdent presque jamais.

03Le parti pris #sec_d821c25a

Le produit délègue la vérification de l'identité, jamais la décision de ce qu'il accepte.

REVIEWIT introduit une autorité d'authentification interne. Les applications ne parlent plus à un fournisseur d'identité : elles parlent à cette autorité, dans un langage standard. L'autorité, elle, se charge d'aller vérifier l'identité auprès du fournisseur du client, quel qu'il soit.

Le gain est double. Le client garde son annuaire, ses règles, sa politique d'authentification. Et le produit gagne un endroit unique où raisonner sur ce qu'il accepte — au lieu de le laisser à quatre applications qui le feraient chacune à sa façon.

Six principes structurent ce choix. Ce sont eux qui font la différence entre « ça marche » et « ça tient devant un audit ».

1. La preuve fait foi, jamais la demande

C'est le principe le plus important, et le plus contre-intuitif.

Une application peut demander au fournisseur d'identité une authentification forte. Mais cette demande n'est qu'une demande : selon le fournisseur, sa configuration, l'état de la session ou la politique en vigueur, elle peut être partiellement honorée, ignorée, ou silencieusement contournée.

REVIEWIT ne se fie donc jamais à ce qu'il a demandé. Il vérifie ce qui revient , et si la preuve attendue n'est pas là, l'accès est refusé. Demander est un effort de bonne volonté ; vérifier est la garantie.

C'est ce qui sépare une politique de sécurité affichée d'une politique de sécurité effective.

2. Le niveau d'assurance, pas le mécanisme

Les applications ne raisonnent jamais sur « la personne a-t-elle utilisé tel dispositif ». Elles raisonnent sur un niveau d'assurance ordonné :

Un écran exige un niveau minimal ; le mécanisme qui l'a produit ne le regarde pas. L'avantage est durable : quand un nouveau moyen d'authentification apparaît, il suffit de savoir à quel niveau il correspond — aucune application n'est à modifier.

Le produit conserve aussi le moment de l'authentification, ce qui permet d'exiger une authentification récente pour un geste sensible, et non seulement une authentification valide. Cette information n'est jamais reconstituée par approximation : si elle manque, la règle de fraîcheur échoue plutôt que de laisser passer.

3. Jamais de rapprochement automatique par adresse e-mail

Lorsqu'une identité inconnue se présente, la tentation est de la rattacher à un compte existant portant la même adresse. REVIEWIT ne le fait jamais.

L'adresse e-mail n'est pas une preuve d'identité : elle est déclarative, réattribuable, et falsifiable chez un fournisseur mal configuré. Un rapprochement automatique sur ce critère est un vecteur classique de prise de contrôle de compte — il suffit de faire émettre une identité portant la bonne adresse pour hériter des droits de quelqu'un d'autre.

Le lien entre une identité externe et un compte REVIEWIT est donc établi sur un triplet stable — le fournisseur, l'émetteur, l'identifiant du sujet — et un rapprochement entre plusieurs fournisseurs relève d'un flux contrôlé et explicite, jamais d'une déduction.

4. Le compte REVIEWIT est l'autorité de session

Une authentification réussie chez le fournisseur du client ne suffit pas à ouvrir une session.

Le produit tient son propre registre de comptes, et ce registre tranche : un compte désactivé côté REVIEWIT se voit refuser l'accès même si le fournisseur d'identité vient de l'authentifier avec succès. Les deux cycles de vie sont séparés — révoquer un lien d'identité n'est pas désactiver un compte, et inversement.

Cette vérification est rejouée à chaque émission d'accès , y compris lors des reconnexions silencieuses que permet la session unique. C'est précisément le cas où l'on pourrait croire qu'il n'y a « rien à revérifier » — et c'est le cas où une désactivation resterait sinon sans effet pendant des heures.

5. Identité et contexte ne se confondent pas

L'autorité d'authentification établit qui vous êtes . Elle ne décide jamais à quoi vous avez droit , ni à quelle souscription ou quel workspace vous appartenez.

Lorsqu'un contexte est transmis, il l'est comme un indice signé — utile pour éviter à l'utilisateur de resélectionner son périmètre — et jamais comme une preuve d'appartenance. L'application revérifie systématiquement les droits comme si cet indice n'existait pas.

Confondre les deux est l'erreur qui produit les élévations de privilèges les plus discrètes : un jeton qui affirme un périmètre finit toujours par être cru.

6. Les secrets ne sont pas dans la base

La base contient la référence d'un secret, jamais sa valeur. Les secrets vivent dans un magasin dédié, avec un mécanisme de rotation à double version : le nouveau secret devient actif pendant que l'ancien reste accepté le temps de la bascule, puis est révoqué.

Le même raisonnement vaut pour les clés : celles qui signent les jetons destinés aux humains sont distinctes de celles destinées aux machines, avec des émetteurs et des destinataires explicites. Un jeton émis pour une application n'est jamais acceptable là où un autre est attendu — les mécanismes sont mutualisés, jamais les secrets.

04Deux autorités, délibérément séparées #sec_dd4e68e8

Ces deux mondes ont des menaces, des cycles de vie et des exigences différents. Les faire cohabiter dans une même autorité conduirait tôt ou tard à ce qu'un jeton conçu pour l'un soit accepté par l'autre. Voir le [dossier API](REVIEWIT_Dossier_API_v1.0.md).

05Le fournisseur d'identité du client #sec_9c97a8ca

Chaque souscription déclare son ou ses fournisseurs d'identité. L'aiguillage se fait sur le domaine de l'adresse professionnelle : l'utilisateur saisit son adresse, et il est envoyé chez le fournisseur qui le concerne.

Les fournisseurs conformes aux standards modernes sont pris en charge nativement, ce qui couvre l'essentiel du parc, y compris les annuaires d'entreprise auto-hébergés dans leurs versions récentes. Les protocoles plus anciens sont traités par adaptateur, dans un second temps.

Un point de conception mérite d'être signalé : la connexion des utilisateurs et la collecte des données sont deux chemins distincts . Les autorisations dont le produit a besoin pour inventorier les ressources d'un client ne transitent jamais par le parcours de connexion. Un utilisateur qui se connecte n'accorde rien d'autre que son identité — et une modification de la configuration de collecte ne peut pas casser l'authentification.

06Les accès de secours #sec_5e779c5b

Le produit prévoit des comptes de secours, pour le cas où le fournisseur d'identité du client serait indisponible.

Deux garde-fous : ces comptes sont explicitement désignés , un par un — il n'existe pas de règle du type « tous les administrateurs peuvent se connecter autrement » — et leur usage fait l'objet d'un enregistrement renforcé dans la [piste d'audit](REVIEWIT_Dossier_PisteAudit_v1.0.md).

Un accès de secours est une exception assumée, pas une porte dérobée permanente.

07Un choix assumé : le remplacement à blanc #sec_50dd8f34

L'ancien dispositif d'authentification n'est pas migré, il est remplacé . Aucun double chemin, aucune période où les deux coexistent.

La raison est de sécurité, pas de confort. Maintenir deux chemins d'authentification, c'est maintenir deux surfaces d'attaque, deux jeux de secrets, et l'obligation permanente de vérifier que le plus faible des deux ne peut pas être emprunté pour contourner l'autre. Les anciennes inscriptions applicatives sont décommissionnées et leurs secrets révoqués.

C'est le même raisonnement que pour la [piste d'audit](REVIEWIT_Dossier_PisteAudit_v1.0.md) : mieux vaut un socle court et net qu'un socle long dont on ne peut rien affirmer.

08Ce que le produit ne fait pas #sec_c39b58a6

• Il ne gère pas de mots de passe. REVIEWIT n'en stocke aucun, n'en vérifie aucun, et n'en fait expirer aucun. C'est le métier du fournisseur d'identité du client.
• Il n'implémente pas son propre multifacteur. Le renforcement de l'authentification s'appuie sur les dispositifs du client. Ce que le produit apporte, c'est la capacité d' exiger et de vérifier un niveau donné — pas de le fournir.
• Il ne décide pas des droits. L'authentification établit l'identité ; les habilitations sont portées par le workspace et la souscription.
• Il ne fait pas confiance à une déclaration. Ni l'adresse e-mail, ni un contexte annoncé, ni une demande d'authentification forte ne valent preuve.

09À retenir #sec_5948ea3f

L'authentification est la fondation sur laquelle tout le reste repose : sans elle, « Marie a certifié cet accès le 14 mars » est une affirmation invérifiable.

REVIEWIT s'appuie sur l'identité que le client maîtrise déjà, mais garde la main sur ce qu'il en accepte. Il vérifie les preuves au lieu de se fier aux demandes, raisonne en niveaux d'assurance plutôt qu'en mécanismes, refuse les rapprochements commodes qui font les prises de contrôle, et se réserve le dernier mot sur l'ouverture d'une session.

C'est ce qui permet d'affirmer non seulement qu'une décision a été prise , mais par qui, et avec quel degré de certitude .