Autorisation sans authentification

L’authentification et l’autorisation résolvent des problèmes différents

La plupart des applications commencent par une barrière. Avant de pouvoir agir, l’utilisateur doit établir son identité : saisir un e-mail, recevoir un code de vérification, choisir un mot de passe ou suivre un lien magique. Cette étape est l’authentification, le fait de confirmer qui est une personne face à un enregistrement détenu par une autorité centrale.

L’autorisation répond à une autre question : qu’a le droit de faire cette personne ? Les équipes regroupent souvent les deux dans un unique flux de « connexion », mais ce sont des opérations distinctes. Les séparer met au jour une idée utile.

Un serveur n’a pas besoin de savoir qui est un utilisateur pour appliquer ce qu’il a le droit de faire.

JustCall repose sur cette séparation. Il n’y a ni inscription, ni table de comptes, ni mot de passe, ni données personnelles sur le serveur. L’autorisation porte tout le système, tandis que l’authentification au sens classique est absente. Trois briques rendent cela possible : une clé privée, une clé publique et un rôle délégué que nous appelons la clé maîtresse.

Comment l’identité par clé publique remplace les comptes

La première fois que vous ouvrez JustCall, le navigateur génère un secret localement et ne le transmet jamais. De ce secret il dérive une paire de clés, et la moitié publique devient votre identifiant utilisateur :

// The private key is generated on your device. The server never sees it.
privateKey = crypto.randomUUID();

// The PUBLIC half, encoded as text, becomes your user ID.
userId = await derivePublicUserId(privateKey);

L’identifiant est la clé publique elle-même, pas une ligne de base de données qui y renvoie. Cette seule décision supprime plusieurs risques que portent les systèmes de comptes traditionnels :

Aucune étape d’inscription. Le serveur accepte les requêtes signées par un identifiant dès qu’il le voit pour la première fois.
Ni e-mail ni numéro de téléphone. L’identifiant dérive d’un secret aléatoire sur votre appareil, et non d’une donnée personnelle.
Aucun mot de passe. Il n’y a aucun secret partagé à stocker, hacher ou divulguer, car le serveur ne détient que la clé publique.
Aucun flux de réinitialisation de mot de passe ni bourrage d’identifiants, car il n’y a aucun identifiant réutilisable à attaquer.

Vous ne révélez jamais d’identité au serveur. Vous prouvez, de façon cryptographique, que vous détenez la clé privée derrière une clé publique donnée, et cette preuve suffit comme autorisation.

Comment le serveur autorise une requête

Sans sessions ni jetons de connexion, chaque requête porte sa propre preuve. Le client construit une charge utile, la signe avec la clé privée et envoie les deux. Côté serveur, l’autorisation se réduit à une seule vérification de signature, sans recherche de session ni interrogation d’un magasin d’identifiants :

const isValid = await verifyPayload(
  request.userId,   // the public key = the claimed identity
  request.payload,  // exactly what was signed
  request.signature,
);

if (!isValid) {
  return jsonResponse({ message: "invalid signature" }, 401);
}

Une signature valide rend la requête authentique et autorisée en une seule opération. Un attaquant ne peut pas falsifier une requête pour un identifiant dont il ne détient pas la clé privée, car il ne peut pas produire de signature correspondante. La possession de la clé privée est l’autorité.

La clé maîtresse : relier des appareils sans partager de secrets

Un modèle où un seul appareil détient l’unique clé s’effondre dès qu’on ajoute un deuxième appareil. Si votre téléphone détient l’unique clé de votre identité, votre ordinateur portable est un inconnu pour le système.

La clé maîtresse règle ce point. Le premier appareil devient le maître et détient le secret d’origine dont dérive votre identifiant. Chaque appareil supplémentaire génère sa propre paire de clés distincte. Un nouvel appareil ne peut pas signer en votre nom, et la clé maîtresse n’est jamais copiée d’un appareil à l’autre. La liaison fonctionne par délégation : le maître signe un court certificat qui lie la clé publique du nouvel appareil à votre identifiant.

// Only the master can authorize a new device.
const authorization = {
  action: "device-authorization",
  userId: identity.userId,
  devicePublicKey: newDevice.devicePublicKey, // the new device's PUBLIC key
  role: newDevice.role,
  createdAt: Date.now(),
};
const signature = await signPayload(identity.privateKey, authorization);

Dès lors, le nouvel appareil signe ses propres requêtes avec sa propre clé, et le serveur les vérifie face à la clé pour laquelle le maître s’est porté garant. Le maître délivre un titre d’accès sans jamais exposer son secret, de la même façon qu’une autorité de certification se porte garante d’un site dont elle ne détient pas la clé privée.

Vous obtenez ainsi tout le vocabulaire d’un système de permissions en production : rôles, délégation, révocation et moindre privilège, le tout exprimé par des signatures. Le maître peut renommer ou révoquer tout appareil lié, et un appareil révoqué échoue à sa prochaine vérification de signature tandis que sa connexion active se ferme.

Ce que stocke un serveur sans comptes

Regardez ce que contient réellement la base. Chaque compte détient un nom d’affichage choisi par l’utilisateur, un avatar facultatif et une liste de clés d’appareil publiques. Rien d’autre. Il n’y a ni e-mails, ni numéros de téléphone, ni empreintes de mot de passe, ni questions de sécurité, et aucune clé privée, qui ne quittent jamais les appareils de l’utilisateur.

Considérez le scénario de fuite classique où toute la base s’échappe. L’attaquant obtient un ensemble de clés publiques, publiques par conception et inutiles sans les clés privées correspondantes, ainsi que quelques noms d’affichage choisis par les utilisateurs. Il ne peut usurper personne, car l’usurpation exige une clé privée que le serveur n’a jamais stockée. Il ne peut recouper les utilisateurs avec une fuite de mots de passe, car aucun mot de passe n’existe. Il ne peut hameçonner personne via « votre e-mail », car aucun n’a jamais été collecté.

Un système ne peut pas faire fuiter des données qu’il ne détient jamais. La manière la plus fiable de protéger les données personnelles est de ne pas les collecter, et un modèle d’identité où l’identifiant est une clé publique rend cela littéral.

Pourquoi l’autorisation sans mot de passe réduit le risque de fuite

Comparez directement les surfaces d’attaque. Une app classique avec e-mail et mot de passe doit défendre une base d’identifiants, des flux de réinitialisation de mot de passe, l’envoi de codes par e-mail et SMS, des jetons de session et un ensemble de données personnelles réglementées dont elle est désormais responsable. Chacun est une source récurrente de vols de compte et d’incidents de fuite.

Le modèle à clé publique défend une seule chose : que l’utilisateur conserve sa clé. C’est un vrai compromis, car aucune autorité centrale ne peut réinitialiser une clé perdue. En échange, chaque élément de la liste précédente disparaît. L’impact d’un serveur compromis se réduit à un attaquant lisant des clés publiques et des noms d’affichage, des informations qui n’ont jamais été sensibles.

Appliquer l’autorisation par clé publique dans votre propre app

Le schéma se généralise bien au-delà d’une app d’appel :

Faites de l’identité une paire de clés et de l’identifiant utilisateur la clé publique. Générez-la côté client, ne transmettez jamais la moitié privée et laissez le compte naître dès que le serveur voit une signature valide.
Autorisez en vérifiant des signatures plutôt qu’en vérifiant des sessions. Chaque action porte une charge utile et une signature. Signez sur des octets canoniques pour que client et serveur s’accordent sur ce qui a été signé.
Utilisez une clé maîtresse pour déléguer, non pour partager. Quand une entité doit étendre la confiance à un deuxième appareil, à un coéquipier ou à un client d’API, faites signer par la clé racine un certificat délimité et révocable pour une nouvelle clé. Le secret racine ne bouge jamais.
Ne stockez que du matériel public, pour que la réponse à « que se passe-t-il en cas de fuite » reste banale.

Quelques contraintes méritent attention avant la mise en production. La garde des clés devient le problème central, donc les systèmes en production ajoutent des options de récupération comme la récupération sociale, une sauvegarde chiffrée optionnelle ou une clé matérielle. Les requêtes signées ont besoin d’un horodatage ou d’un nonce pour empêcher le rejeu. Comme il n’y a pas d’identité, la prévention du spam passe à la limitation de débit ou aux invitations plutôt qu’à la vérification par e-mail. Rien de tout cela n’affaiblit le modèle. Ce sont les préoccupations ordinaires de tout système, sans la base de mots de passe au milieu.

Questions fréquentes

Comment une app peut-elle autoriser un utilisateur sans authentification ? Elle traite la possession d’une clé privée comme l’autorité. La clé publique sert d’identifiant utilisateur, chaque action est signée par la clé privée correspondante, et le serveur vérifie cette signature face à la clé publique. L’utilisateur prouve qu’il a le droit d’agir sans prouver son identité à un système central de comptes.

Un modèle sans compte est-il moins sûr qu’e-mail et mot de passe ? Dans la plupart des aspects, il est plus sûr. Il n’y a pas de base de mots de passe à faire fuiter, pas de flux de réinitialisation à abuser, pas de données personnelles à perdre. Le compromis est la garde de la clé : si un utilisateur perd sa clé sans sauvegarde, aucune autorité centrale ne peut récupérer le compte.

Quelle est la différence entre authentification et autorisation ? L’authentification établit qui vous êtes. L’autorisation établit ce que vous avez le droit de faire. La plupart des systèmes les combinent, mais une paire de clés permet la seconde sans la première.

Que se passe-t-il si les serveurs de JustCall sont compromis ? Un attaquant trouverait des clés publiques et des noms d’affichage. Les clés publiques sont faites pour être publiques et sont inutiles sans les clés privées, qui ne quittent jamais vos appareils. Il n’y a ni mots de passe, ni e-mails, ni numéros de téléphone à voler.

Puis-je utiliser plusieurs appareils sans compte ? Oui. Le premier appareil agit comme maître et signe un certificat qui lie la clé publique de chaque nouvel appareil à votre identifiant. Le secret maître n’est jamais copié, et le maître peut révoquer n’importe quel appareil à tout moment.