Aller au contenu

Le problème : tu as un produit, il a des utilisateurs, et tu ne veux ni écrire une authentification ni en confier une de plus à un tiers. Auth fait de Tock le fournisseur d'identité de ton produit : un serveur OpenID Connect complet, par projet, avec ses propres utilisateurs finaux.

Deux populations qui ne se mélangent jamais : les comptes Tock (toi, ton équipe) et les utilisateurs finaux de ton produit, qui n'ont accès à rien chez Tock et n'existent que dans le périmètre d'un projet. Deux tables, jamais un drapeau — un drapeau finit toujours par être oublié dans une clause WHERE, et ce jour-là l'utilisateur d'un client entre chez un autre.

Démarrer en 30 secondes

1. Sur /auth, ouvre l'authentification pour ton projet. Tu obtiens une clé d'émetteur, par exemple k3f9wq. 2. Déclare ton application : son nom, son type (public pour ce qui tourne dans un navigateur, confidentiel pour un serveur), et ses adresses de redirection. 3. Pointe ta bibliothèque OIDC sur l'adresse de découverte :

   https://letock.fr/o/k3f9wq/.well-known/openid-configuration

C'est tout. N'importe quelle bibliothèque OIDC correcte lit ce document et se configure seule. Il n'y a pas d'API propriétaire à apprendre.

Les points d'entrée

Pour une clé d'émetteur <cle> :

GET  /o/<cle>/.well-known/openid-configuration   la découverte
GET  /o/<cle>/autoriser                          l'écran d'autorisation (navigateur)
POST /api/oidc/<cle>/token                       l'échange du code, et le rafraîchissement
GET  /api/oidc/<cle>/userinfo                    les informations du compte, jeton porteur
GET  /api/oidc/<cle>/jwks                        les clés publiques de signature
GET  /o/<cle>/deconnexion                        la fin de session

L'émetteur (iss) des jetons est https://letock.fr/o/<cle>. Il ne change jamais : c'est pourquoi la clé d'Auth est distincte de celle du forum, qui, elle, peut être renommée.

Ce qui est implémenté, et strictement

  • Code d'autorisation avec PKCE `S256`, exigé pour tous les clients, y compris les confidentiels. Un secret de client fuite aussi, et PKCE ne coûte rien.
  • Redirections comparées à l'identique, jamais par préfixe. Un préfixe autorise une redirection vers un chemin que le client n'a pas choisi : c'est la voie classique du vol de code d'autorisation. HTTPS obligatoire, sauf sur localhost.
  • Un code ne vaut qu'une fois. Un second échange n'est pas une erreur, c'est une attaque : les jetons déjà émis pour ce code sont révoqués.
  • Rotation des jetons de rafraîchissement. Rejouer un jeton déjà remplacé révoque toute la chaîne — la seule défense contre un jeton volé qu'on ne peut pas distinguer autrement.
  • Signature RS256, clés publiées en JWKS. Plusieurs clés coexistent le temps d'une rotation.
  • Durées : code 60 secondes, jeton d'accès 15 minutes, rafraîchissement 30 jours, session hébergée 30 jours.

Les portées

openid    l'identifiant du compte (obligatoire, c'est elle qui rend la demande OIDC)
email     l'adresse et si elle est vérifiée
profile   le pseudo

Trois portées, et pas trente. Une portée qu'on ne sait pas expliquer en une ligne sur l'écran d'autorisation est une portée que l'utilisateur accepte sans comprendre.

Comment tes utilisateurs se connectent

Par lien reçu par e-mail, valable 15 minutes, cinq demandes par heure et par adresse. Pas de mot de passe : un mot de passe qu'on stocke est un mot de passe qu'on peut perdre, et la moitié des incidents de sécurité d'un petit produit commencent là.

Une session ouverte sur l'écran de Tock vaut pour toutes tes applications : c'est ce qui évite de redemander à l'utilisateur de s'identifier à chaque application.

Écrans

/auth — ouvrir l'authentification, déclarer et révoquer les applications, voir les utilisateurs finaux du projet, en bloquer un, révoquer toutes ses sessions. /o/<cle>/compte — l'écran que voit l'utilisateur final : ses sessions, sa déconnexion. Il n'y verra jamais rien de Tock.

Quotas

applicationsAuth (applications déclarées par projet) et utilisateursAuth (comptes d'utilisateurs finaux) : deux quotas de la famille « ce qui existe », plafonnés par le forfait de l'équipe. Les liens de connexion envoyés comptent dans le poste envois.

Pièges

  • Un client public ne reçoit pas de secret. Lui en donner un donnerait l'illusion d'une protection : tout ce qui part au navigateur est lisible.
  • Le secret n'est montré qu'une fois. Seule son empreinte est conservée. Un secret perdu se remplace, il ne se retrouve pas.
  • Vérifie toujours `iss` et `aud` côté application. Un jeton signé par Tock pour un autre projet est un jeton parfaitement valide — qui ne parle pas de toi.
  • Ne fabrique pas les URL à la main. Lis la découverte : les chemins peuvent changer, le document de découverte, lui, dit toujours la vérité.
  • Une adresse e-mail, un compte, par projet. Le même utilisateur chez deux de tes clients aura deux comptes qui ne se touchent pas. C'est voulu.