Produit
Authentification unique (SSO) illimitée. Même facture. Même code.
Pointez le client better-auth standard vers une instance. Ajouter le fournisseur d'identité d'un client potentiel est un changement de configuration, pas un bon de commande. Les utilisateurs, les sessions et les secrets résident dans votre Postgres. Pourquoi nous fixons les prix ainsi est une note datée.
Ce qui est réaliséJetons d'agentLa connexion de votre applicationVotre instanceVotre PostgresLes vérifications datéesAnnexe
[server]
listen = "0.0.0.0:3000"
base_url = "https://auth.example.com"
[database]
adapter = "postgres" # or SIGNET_DATABASE_URL
# users, sessions + secrets live in YOUR Postgres| Qui se connecte | Ce qu'ils détiennent | Comment ils arrivent | Comment révoquer leur accès |
|---|---|---|---|
| Personnes | une session | courriel, clé d'accès, SSO | revoke |
| Services | un jeton | créé une seule fois | revoke |
| Agents | un jeton à portée limitée | authentification MCP | revoke |
Ce qui est réalisé.
Ce que le moteur fait aujourd'hui, une ligne par capacité, chacune avec sa preuve. La règle de ce tableau : réalisé et testé signifie inscrit; partiel ou non démontré signifie explicitement limité ou absent. Rien n'y dépasse les éléments consignés, et le /docs intégré de toute instance en service est la référence à laquelle il doit correspondre.
| Capacité | État | Preuve |
|---|---|---|
| Courriel + mot de passe | réalisé | Inscription et connexion par le protocole certifié, avec politique de mot de passe, vérification des mots de passe compromis et parcours de réinitialisation. |
| Liens magiques | réalisé | Envoi et vérification. Une connexion effectuée dans un vrai navigateur. |
| Code à usage unique par courriel | réalisé | Codes à usage unique pour la connexion, la vérification du courriel, la réinitialisation du mot de passe et le changement de courriel. |
| Clés d'accès (WebAuthn) | réalisé | Cryptographie réelle du protocole sur quatre routes, testée avec un authentificateur logiciel. |
| Deux facteurs | réalisé | TOTP, code à usage unique envoyé par courriel comme second facteur et codes de secours à usage unique; le parcours de récupération après perte de l'authentificateur est testé de bout en bout dans un navigateur. |
| Connexion par réseaux sociaux | réalisé | Connexion, association et dissociation de fournisseurs en amont par le même protocole. |
| Organisations + invitations | réalisé | Douze routes d'organisation : membres, invitations, rôles. |
| Clés API | réalisé | Cinq routes pour émettre et gérer les identifiants programmatiques. |
| Flux par code d'appareil | réalisé | Cinq routes : connectez une CLI ou un téléviseur depuis un autre appareil. |
| Authentification MCP | réalisé | Cinq routes d'authentification destinées aux agents; l'appelant machine est un client à part entière. |
| Jetons d'agent (liés au destinataire) | réalisé | Un jeton d'accès dont la durée de vie va de cinq minutes à une heure selon une seule clé de configuration, qui nomme jusqu'à huit API auxquelles il peut être présenté, ne porte que les portées approuvées par la personne connectée et est reconnu comme révoqué à chaque point d'accès dès sa révocation. Les interfaces OAuth et MCP lisent la même clé et la même liaison : elles ne peuvent donc pas diverger. Ce que cela apporte → |
| Inventaire des sessions et des jetons | réalisé | Énumérez et révoquez les sessions et jetons en cours depuis la console et par le protocole. |
| Fournisseur OAuth2 / OIDC | réalisé | Signet émet des jetons en tant que fournisseur : code d'autorisation avec PKCE, renouvellement avec détection de réutilisation et identifiants client, ainsi que découverte, JWKS, userinfo, introspection, révocation et enregistrement dynamique des clients. Il signe les jetons d'identité en EdDSA ou en RS256, selon le choix du client. Signet vérifie d'autres algorithmes provenant de fournisseurs d'identité externes; cette vérification est distincte de la signature. Cela ne constitue pas une conformité complète à OIDC Core. |
| SSO d'entreprise (SAML + OIDC) | périmètre limité | Le transport OIDC a été testé avec un environnement Microsoft Entra en service : connexion réelle, MFA, échange de jetons lié au locataire et création de l'organisation au rappel. SAML effectue des allers-retours complets avec un fournisseur d'identité servant aux tests de conformité au protocole, mais n'a pas encore été testé avec un fournisseur commercial : la ligne reste donc limitée au transport qui l'a été. |
| Agents gérés par l'entreprise | périmètre limité | Le moteur accepte une décision d'autorisation signée par le fournisseur d'identité qu'utilise déjà votre client, puis crée un jeton correspondant, sans faire circuler de secret par locataire par courriel. Réalisé selon le profil finalisé et testé avec un fournisseur d'identité signataire que nous exploitons nous-mêmes; aucune capture d'un locataire commercial en service n'est encore consignée, et cette ligne ne le revendique donc pas. Comment c'est vérifié → |
| Approvisionnement SCIM | périmètre limité | Signet prend en charge l'approvisionnement et le retrait des utilisateurs par SCIM avec Microsoft Entra. Lorsqu'un utilisateur est retiré, son appartenance à l'organisation est supprimée et ses sessions actives ainsi que ses jetons OAuth sont révoqués; la personne perd l'accès à l'organisation, et le compte lui-même subsiste, par conception. Les groupes font l'objet d'un refus typé et aucun autre fournisseur d'identité n'a été testé, donc ni l'un ni l'autre n'est revendiqué. |
| Webhooks d'événements | réalisé | Événements signés avec nouvelles tentatives durables. Chaque instance sert le contrat du récepteur à /docs/event-webhooks avec des vecteurs de test épinglés, et signet events verify-receiver exécute neuf cas de conformité contre votre propre point de terminaison. Un récepteur a été construit à partir de la page servie seule, sans accès au code source. |
| Règles de connexion + attributs de jetons | réalisé | Filtrez une inscription ou une connexion et façonnez les attributs des jetons depuis signet.toml, sans recompilation : règles sur le courriel et le domaine, méthode d'authentification, fournisseur, client OAuth; attributs par client; champs utilisateur typés. Un refus se lit exactement comme un mauvais mot de passe, de sorte qu'une règle ne peut jamais servir à repérer des comptes. |
| Stockage : PostgreSQL + SQLite chiffré | réalisé | PostgreSQL est le palier certifié. Un fichier SQLite chiffré par instance (SQLCipher) est un palier pris en charge, avec changement de clé hors ligne et sauvegarde par point de contrôle, et il peut migrer vers Postgres. SQLite n'est pas certifié, pas hautement disponible, et un seul processus par fichier. |
Ce qui est absent de ce tableau est absent du produit aujourd'hui. S'il manque une capacité dont vous avez besoin, demandez-nous. La réponse pourrait être une date.
Donnez à un agent un jeton qui expire en quelques minutes.
Votre agent se connecte en tant que personne qui l'utilise. Le jeton qu'il reçoit nomme l'API à laquelle il peut être remis. Sa durée de vie est courte. Il cesse de fonctionner quand vous le révoquez. Et chaque point d'accès donne la même réponse à son sujet.
Quand la décision vient du propre fournisseur d'identité de votre client plutôt que de votre application, c'est le parcours géré par l'entreprise →
Pointez un client better-auth vers l'instance.
De votre côté, l'intégration est une URL de base. Le client reste le paquet better-auth standard que vous utilisez déjà : il pointe vers votre instance Signet au lieu de votre fournisseur actuel, et les appels que vous avez écrits continuent de fonctionner. Cela vaut pour une instance que nous hébergeons comme pour une instance sur vos propres serveurs sous licence d'entreprise : les requêtes de votre application restent les mêmes, même quand le moteur change d'adresse.
import { createAuthClient } from "better-auth/client";
// Votre client better-auth actuel : pointez baseURL
// vers votre instance Signet. Le protocole est le contrat.
export const authClient = createAuthClient({
baseURL: "https://auth.example.com/api/auth",
});
// Les mêmes appels que vous écrivez déjà. Ils fonctionnent.
await authClient.signIn.email({ email, password });- L'instance se vérifie avant de servir. Sa configuration est validée sans aucun réseau, puis validée de nouveau avec l'URL en service; les deux vérifications sont dans le moteur, sans outil externe à installer ni auquel faire confiance.
- Aucun secret ne réside dans le fichier de configuration. Le secret de signature et l'URL de la base de données sont fournis séparément au processus, et le schéma s'applique au premier démarrage.
- Vous pointez votre client better-auth vers
/api/auth. C'est tout le changement de votre côté : une URL. Elle se lit de la même façon en hébergement ou sur vos propres serveurs.
Vous utilisez un cadriciel? Le guide de démarrage propose cinq parcours concrets : Next.js, React Router v7, Node/Express, Vue 3 et Svelte, ainsi que les bases pour React et le client standard.
Ce que sert une instance Signet.
Les routes auxquelles une instance en service répond. Ouvrez pour lire la liste.
/llms-full.txtGuides concis et détaillés pour les agents d'IA. Une instance dérive l'inventaire de ses points de terminaison activés de la même source qu'OpenAPI; le complément du site de présentation reste limité aux indications sur le produit et l'intégration.machine
La documentation n'est pas un site distinct : chaque instance déployée sert ses propres /docs, /llms.txt et /llms-full.txt dérivé de l'inventaire depuis le moteur, pour que sa référence des routes reste liée à la version que vous exécutez.
Annexe
Chaque point de terminaison, par domaine.
La référence API, condensée en preuves du produit. Chaque ligne renvoie au README.md du dépôt ou au /docs intégré que sert une instance en cours d'exécution. Si elle n'y figure pas, elle n'est pas sur cette page. Ouvrez pour lire les lignes.
README.md du dépôt ou au /docs intégré que sert une instance en cours d'exécution. Si elle n'y figure pas, elle n'est pas sur cette page. Ouvrez pour lire les lignes.| Domaine | Ce qui est retourné | Ce que vous obtenez |
|---|---|---|
| Inscription | sign-up auto_sign_in | Création de compte par le protocole certifié. Activez auto_sign_in et un nouvel utilisateur est connecté immédiatement après l'inscription, sans connexion séparée. |
| Connexion | sign-in/email | Connexion par courriel. La documentation intégrée utilise ce chemin comme exemple de limitation du débit par chemin. |
| Sessions | session expires_in fresh_age | La durée de vie est de sept jours par défaut (expires_in) et se renouvelle à l'utilisation (update_age); une fenêtre configurable fresh_age contrôle les actions sensibles. |
| OAuth + OIDC | social_providers pkce | Connexion par réseaux sociaux sur le même protocole certifié : google et github ont des valeurs par défaut intégrées, les fournisseurs personnalisés déclarent leurs points de terminaison, PKCE est disponible. Un module oauth_proxy facultatif est livré. |
| Politique de mot de passe | password | 8–128 caractères par défaut; évaluation facultative de la robustesse du mot de passe et facteur de coût de hachage réglable. |
| Vérifications préalables en CLI | init doctor env pull | La même version crée une configuration sans secrets sans écraser les fichiers, valide la configuration ou une instance en service et écrit l'URL publique du client sans extraire les secrets du serveur. |
| Vérification des mots de passe compromis | haveibeenpwned | Vérification facultative par plage avec Have I Been Pwned. Pointez le point de terminaison de plage vers un miroir autohébergé. |
| Envoi de vérification et de réinitialisation | delivery smtp.templates dead_letter | Les codes de vérification et les liens de réinitialisation sont envoyés par webhook JSON signé (signature HMAC), par SMTP, ou pas du tout. Les objets et les corps en texte brut SMTP sont configurables par flux avec des espaces réservés stricts; les envois en échec peuvent être conservés pour une reprise depuis l'interface d'administration. |
| Limitation du débit | rate_limit | Activée par défaut : 100 requêtes par fenêtre de 10 secondes, avec des règles de remplacement par chemin. |
| État de santé et schéma machine | /health open-api/generate-schema | Confirmez l'état de santé à /health; consultez le schéma machine du protocole à /api/auth/open-api/generate-schema. |
Sources : README.md (tableau des interfaces, guide de démarrage) et /docs intégré : lisez la copie d'une instance en service, servie depuis le moteur.
Votre Postgres. La même version, où qu'elle s'exécute.
Chaque utilisateur, session et secret réside dans votre propre PostgreSQL, derrière une API /admin que vous contrôlez. Signet est la même version, que nous l'exécutions ou que vous le fassiez : commencez sur une instance gérée et, le jour où il le faut, transférez-la sur votre propre matériel sous licence d'entreprise, sans changer une ligne de code client. Le protocole ne change pas.
Partir se fait avec pg_dump, pg_restore, puis un démarrage. Sur votre propre matériel, vous le faites vous-même et partir ne demande l'aide de personne. Avec le service hébergé, nous exploitons la base : vous demandez et nous vous remettons le fichier d'export. Une licence d'entreprise met le moteur entre vos mains : si nous disparaissions demain, votre authentification continuerait de fonctionner et les requêtes ne changeraient jamais.
La propriété s'étend aussi à la configuration : chaque paramètre réside dans signet.toml, dans votre propre dépôt, pas dans une console hébergée. La configuration est le tableau de bord →
Ce que couvrent les vérifications datées, et ce qu'elles ne couvrent pas.
La série de tests de conformité différentielle est de 280 / 280 : chaque vérification du profil public de compatibilité s'exécute sur l'implémentation de référence et sur Signet, puis les résultats sont comparés. Le profil ne compte que les vérifications que l'implémentation de référence réussit elle-même; Signet n'est pas évalué sur celles auxquelles la référence échoue. L'écart de compatibilité (une vérification que la référence réussit et à laquelle Signet échoue) est de 0.
Séparément, l'acceptation de bout en bout est de 14 / 14 : le client non modifié de better-auth exécute de vrais parcours d'inscription, de session, d'organisation et de deux facteurs. Les deux exécutions ont été consignées le 2026-07-22. L'attestation de compatibilité est une référence datée à ces exécutions, pas une attestation cryptographique sous-entendue, et chaque instance sert sa propre copie pour que vous puissiez la vérifier vous-même.
| Propriété | Valeur |
|---|---|
| Profil de compatibilité | better-auth 1.6.23 |
| Version du profil | Signet compatibility profile v1 |
| Conformité différentielle | 280 / 280 |
| Écart de compatibilité | 0 |
| Acceptation de bout en bout | 14 / 14 |
| Consigné le | 2026-07-22 |
| Limites d'exploitation | Non publiées. Le nombre maximal d'utilisateurs, le débit soutenu de requêtes et les ressources utilisées sous charge n'ont pas été mesurés; aucun chiffre de capacité n'est donc revendiqué. Des limites mesurées seront ajoutées une fois consignées. |
L'inscription crée l'instance automatiquement. Le processus se termine par une attestation : une vérification /health en service, plus un test sommaire de bout en bout d'inscription, de connexion et de récupération de session sur l'URL en service. Démontré à partir de zéro le 2026-07-21 : health 200, test sommaire 3/3.
Commencez sur nos serveurs. Passez aux vôtres.
Il n'y a ni version d'essai ni édition réduite. L'instance hébergée est la même version certifiée qu'exécute le titulaire d'une licence d'entreprise.