Une plateforme d’identité et d’accès open source, OpenID Certified™, pour Cloudflare Workers. Authentification, autorisation et fédération reposent sur une architecture conçue pour la périphérie du réseau.
Avant la version 1.0. Les protocoles principaux sont implémentés. Le renforcement et la validation pour la production se poursuivent.
01
Authentification sans mot de passe
Connexion par clé d’accès WebAuthn ou code à 6 chiffres envoyé par e-mail. Les utilisateurs qui n’ont pas encore de clé d’accès disposent ainsi d’une autre méthode sans mot de passe.
02
SSO et fédération d’identité
Reliez vos applications et fournisseurs d’identité existants via OpenID Connect et SAML 2.0. Créez les comptes à la première connexion et associez les identités externes.
03
Contrôle des accès
Gérez les accès selon les rôles (RBAC), les attributs (ABAC) et les relations (ReBAC). Vérifiez les permissions par API, avec des politiques propres à chaque tenant.
04
Mise à l’échelle horizontale
Augmentez automatiquement la capacité de Cloudflare D1 à mesure que le nombre d’utilisateurs progresse. Authrim prévoit la demande et ajoute des partitions de base de données sans changement de plateforme.
Cette conception est née d’un malaise quotidien : enquêter sur un échec de connexion et tomber sur des informations que l’on n’avait pas besoin de voir.
Quand une enquête affiche l’identité
Quand on exploite une plateforme d’identité, cette demande revient : « Un utilisateur n’arrive pas à se connecter. » Pour comprendre, on ouvre l’environnement du client et on retrouve le compte.
Les informations nécessaires sont précises : le compte est-il verrouillé ? Quand et où la dernière tentative a-t-elle échoué ? Quel parcours de connexion a été utilisé ? La clé d’accès est-elle toujours enregistrée ?
Aucune de ces questions ne demande de connaître la personne. Pourtant, en ouvrant le compte, on voit son nom, son adresse e-mail, son téléphone et ses comptes liés. On cherchait un état technique ; on découvre une identité.
« Ne regardez pas » ne protège rien si l’information est déjà affichée.
Personne n’a contourné la procédure. Le client a demandé l’intervention, le technicien a suivi les règles, et les données sont apparues. C’est la structure qui les expose.
Régler cela uniquement par des consignes et des formations revient à dépendre de la mémoire et de la vigilance de chacun. Authrim sépare les données personnelles pour traiter ce problème dans la structure même du système.
Deux bases, dès la conception
Les informations directement identifiantes résident dans une base physiquement distincte. Cette séparation existe dès la couche d’accès aux données.
Les deux dernières lignes à droite comptent : les traces de suppression et de consultation des données personnelles sont conservées séparément, côté PII. L’utilisation de ces données fait l’objet d’un suivi distinct de l’audit courant.
Cette séparation répond au problème initial. Verrouillage, échecs de connexion, appareils : les informations nécessaires sont à gauche. On peut autoriser une enquête sans donner accès à la base de droite. Il n’est plus nécessaire de détourner les yeux.
La même structure facilite aussi les audits. On peut indiquer où résident les noms et les adresses e-mail, et délimiter les données à supprimer. La réponse à un problème d’exploitation rend aussi le système plus facile à expliquer.
Les données personnelles ne se limitent pas à la base PII
Cette distinction est importante : la séparation ne constitue pas une frontière juridique entre données personnelles et non personnelles.
Core DB contient des adresses IP, des informations sur les appareils, l’historique des sessions, les événements d’authentification, des métadonnées d’identifiants et des identifiants utilisateur internes stables. Selon le contexte, ce sont aussi des données personnelles. Leur rapprochement avec d’autres informations peut identifier quelqu’un.
Authrim sépare les données directement identifiantes des données d’identité nécessaires à l’exploitation. L’objectif est de pouvoir enquêter sur les secondes sans consulter les premières, pas de dispenser les secondes de protection.
Il serait donc inexact de dire que les données personnelles sont uniquement dans PII DB. Les noms et adresses e-mail y sont isolés afin d’accorder des droits d’investigation sans ouvrir ce stockage.
La suppression n’est que la première étape
Supprimer un compte est simple à déclencher. Les deux demandes qui suivent le sont moins.
Il faut parfois prouver la suppression : quand, par qui et pourquoi. Il peut aussi falloir empêcher une nouvelle inscription pendant une durée définie.
Ces deux besoins demandent de reconnaître une personne dont on vient de supprimer les données. Conserver les informations qui l’identifient directement irait à l’encontre de cette suppression.
Un index aveugle HMAC-SHA256 permet la comparaison sans stocker la valeur d’origine. On peut vérifier si une adresse a été supprimée ; la table seule ne révèle pas de quelle adresse il s’agissait.
L’implémentation exprime ce choix : ne garder que l’empreinte nécessaire pour éviter les doublons, puis l’effacer à l’échéance, avec la date, l’auteur et le motif de suppression.
Les conditions de la non-récupération
Une précision technique : les adresses e-mail ont une faible entropie. Avec un simple hachage, une attaque par dictionnaire peut retrouver une adresse. La non-récupération n’est pas inconditionnelle.
Authrim utilise un index aveugle HMAC-SHA256 avec une clé secrète et un numéro de génération pour permettre la rotation des clés. Sans cette clé, on ne peut pas tester les adresses candidates en recalculant leurs empreintes.
L’isolement de la clé est donc une condition de cette protection. Stocker la clé avec les empreintes fait perdre cette garantie.
Donner à l’enquête uniquement ce dont elle a besoin
Revenons au signalement de connexion impossible. Il faut trouver où l’authentification s’est arrêtée, sans avoir généralement besoin du nom ou du téléphone.
Authrim sépare les informations directement identifiantes pour accorder l’accès au diagnostic sans ouvrir leur stockage. Lorsqu’une enquête exige ces informations, une personne disposant des droits supplémentaires appropriés intervient.
Le chiffrement et le contrôle d’accès protègent les données ; les journaux d’audit retracent leur utilisation. Le technicien doit aussi pouvoir terminer une enquête courante sans ouvrir les données personnelles inutiles. La séparation du stockage en fait le point de départ de l’exploitation quotidienne.
Implémentation. Séparation du stockage et des accès en place.
Validation. Vérification par les tests automatisés du dépôt.
Maturité opérationnelle. Renforcement en cours. Authrim est en version pré-1.0.
Cette conception facilite les procédures de suppression ; elle ne constitue pas une garantie de conformité juridique. Celle-ci dépend aussi des procédures et des contrats de l’organisation.
Une personne se connecte une fois, mais plusieurs sessions se créent en chemin. Se déconnecter exige de déterminer lesquelles doivent prendre fin sur l’ensemble du parcours.
Une connexion, trois clés
Supposons que votre service propose « Se connecter avec Google ». Pour l’utilisateur, c’est un seul clic.
En coulisses, chaque système du parcours crée et conserve sa propre session. Une chez Google, une chez Authrim, une dans votre application : trois au total.
Une session encore active peut permettre de continuer à utiliser le service ou de se reconnecter sans saisir de mot de passe.
Se déconnecter ne consiste pas seulement à afficher un message. Il faut définir le périmètre, puis terminer les sessions concernées.
La révocation des jetons est une autre opération
Les « clés » désignent ici des sessions. Les jetons d’accès et de renouvellement fonctionnent autrement : terminer une session ne rend pas nécessairement les jetons déjà émis invalides. Leur révocation est une opération distincte.
Dans OIDC, la déconnexion des sessions, la révocation des jetons et la désactivation du compte chez l’IdP amont sont trois opérations différentes. Cet article traite des sessions. Pour les jetons, voir introspection et révocation.
Authrim est au milieu
Dans ce parcours, le fournisseur amont fournit la connexion et votre application la demande. Authrim change de rôle selon le côté auquel il s’adresse.
C’est comme une agence de voyages : elle organise votre trajet, mais achète une place auprès de la compagnie aérienne. Authrim remplit lui aussi ces deux rôles.
La déconnexion s’arrête souvent en chemin
La connexion suit son parcours. La déconnexion, elle, doit être transmise explicitement.
Terminer la session amont ne supprime pas automatiquement celles d’Authrim et de l’application. Il faut transmettre l’arrêt en aval, puis que chaque destinataire termine la session correspondante. Le schéma suppose les méthodes et réglages nécessaires en place.
La différence est la flèche centrale : Authrim peut-il recevoir la notification et la transmettre en aval ? Le fournisseur amont et chaque application doivent également prendre en charge et configurer les méthodes nécessaires.
Ce que cela donne sur le terrain
Situation
Conséquence d’une chaîne interrompue
Départ d’un salarié
Les RH révoquent l’accès. L’application reste ouverte sur l’ordinateur et les données internes restent visibles jusqu’au lendemain.
Terminaux partagés
Commerce, hôpital, centre d’appels : la personne précédente s’est déconnectée, mais un autre onglet affiche encore son tableau de bord.
Appareil perdu
La personne a choisi de se déconnecter partout. Seule la session en cours a réellement pris fin.
Réponse à un incident
Le compte compromis est bloqué. La session de l’attaquant reste pourtant active jusqu’à son expiration.
Audit
Il faut démontrer que la déconnexion se propage à tous les systèmes. Aucune preuve n’est disponible.
Le bouton de déconnexion existe, l’écran change. Pourtant, la portée réelle est plus étroite que prévu. C’est ce qui rend le problème difficile à repérer.
Les limites du passage par le navigateur
Deux méthodes permettent de prévenir les applications. L’une dépend du navigateur et rencontre davantage de restrictions.
La première méthode utilise des cadres invisibles pour notifier chaque application. Les protections de confidentialité des navigateurs peuvent les bloquer. Le back-channel relie directement les serveurs et ne dépend pas de l’état du navigateur. La livraison n’est toutefois pas garantie : panne réseau, destinataire arrêté, délai dépassé ou réponse 5xx restent possibles. Relances, files d’attente et traces d’échec relèvent de l’implémentation.
La certification d’Authrim couvre la réception par back-channel. La réception et l’envoi en aval doivent chacun être vérifiés.
Vérifier le destinataire et l’émetteur
Authrim agit comme Relying Party (RP) envers le fournisseur amont et comme OpenID Provider (OP) envers les applications. Transmettre la déconnexion exige de respecter les spécifications dans les deux rôles.
Côté RP : vérifier la notification reçue et terminer la session Authrim correspondante.
Côté OP : envoyer les notifications permettant aux applications de terminer leurs sessions correspondantes.
Les certifications des profils de déconnexion OP et RP apportent des éléments de vérification pour ces deux rôles. Authrim les a obtenues via la procédure d’auto-certification de l’OpenID Foundation et ses tests officiels de conformité.
La certification atteste que la version soumise a réussi les tests des profils présentés. Elle ne garantit pas la fin immédiate de toutes les sessions dans les applications et le réseau du client.
Les méthodes, points de notification et correspondances de sessions doivent être configurés chez le fournisseur amont et dans chaque application. Désactiver un compte amont ne déclenche pas forcément une notification. Les échecs de livraison et les relances doivent aussi être vérifiés dans la configuration déployée.
Après la déconnexion, où reste-t-il une session active ?
C’est la question lors du passage d’un terminal partagé à un collègue ou du départ d’un salarié. Authrim reçoit et transmet les notifications entre fournisseur amont et applications. La certification renseigne sur l’implémentation ; les essais de l’ensemble connecté vérifient la portée effective de la déconnexion.
Vos mots de passe sont déjà dans Active Directory. Comment ajouter une connexion moderne sans copier leurs empreintes ni exposer un nouveau point d’entrée ? C’est le rôle d’Authrim Relay.
Partir de ce qui ne peut pas changer
Les comptes des salariés sont dans Active Directory. Les règles de mot de passe, leur expiration et les départs y sont gérés depuis des années.
Vous souhaitez ajouter les clés d’accès, organiser l’authentification multifacteur et étendre le SSO aux SaaS. La première question est toujours la même : où vérifier le mot de passe ?
Certaines configurations synchronisent les empreintes de mots de passe vers le cloud ; d’autres demandent à l’annuaire interne de les vérifier. Il faut savoir où vivent les données d’authentification, qui ouvre la connexion et qui exploite ce chemin.
WordWarden laisse la vérification à LDAP/AD et permet de choisir le chemin. Authrim Relay propose une connexion sortante aux organisations qui ne veulent pas publier de nouveau point d’entrée.
Le rôle de WordWarden
Authrim WordWarden est un connecteur d’annuaire, un petit service placé près de LDAP/AD. Il reçoit un nom d’utilisateur et un mot de passe, interroge l’annuaire et renvoie le résultat.
L’interface de connexion, les sessions, les clés d’accès, les codes e-mail, la fédération, la corrélation d’audit et la correspondance des identités restent gérés par Authrim. WordWarden effectue la vérification près de l’annuaire.
Le sens de la connexion change la configuration réseau et les composants à exploiter.
Qui ouvre la connexion ?
WordWarden propose trois modes, selon que votre réseau doit ou non publier un point d’entrée.
Les flèches montrent qui ouvre la connexion. Direct HTTPS part d’Authrim vers un point d’entrée publié. Tunnel et Relay partent tous deux du réseau interne : Tunnel utilise le processus cloudflared, tandis que WordWarden maintient lui-même la connexion Relay.
Quel mode convient à votre environnement ?
Pour un nouveau déploiement sans nouvel accès entrant, examinez d’abord Relay. Une infrastructure de publication ou un tunnel existant peut aussi être pertinent. Les exemples suivants décrivent des configurations possibles, pas des références clients.
Authrim Relay : garder AD en interne sans ajouter d’entrée
Prenez une entreprise où tout nouveau serveur public doit être approuvé, ou une université qui interdit les connexions entrantes vers le réseau LDAP du campus. WordWarden se connecte à Authrim sans publier de nouveau port entrant sur ce réseau.
Ni nouveau point d’entrée public ni processus de tunnel séparé. Les connexions WebSocket sortantes doivent être autorisées ; WordWarden et sa connexion restent à surveiller. Relay ne convient pas à un réseau interdisant toute communication externe.
Cloudflare Tunnel : reprendre une exploitation déjà en place
Si une équipe exploite déjà cloudflared et ses routes pour publier des outils internes, WordWarden peut suivre les mêmes procédures sans ouvrir de nouveau port entrant.
Il faut configurer le nom d’hôte et le chemin permettant aux requêtes d’Authrim d’atteindre le connecteur, et maintenir le tunnel. L’hôte interne n’accepte pas directement de connexions entrantes ; les requêtes passent par Cloudflare.
Direct HTTPS : utiliser une plateforme d’API existante
Une entreprise, une université ou un institut de recherche peut déjà exploiter une DMZ et un proxy inverse pour ses échanges externes. Un point HTTPS accessible depuis Authrim peut alors s’intégrer aux procédures de certificats, de journalisation et de supervision existantes.
Aucune connexion de tunnel ou Relay à maintenir. En contrepartie, l’organisation autorise le chemin entrant et protège le point d’entrée public. Elle publie l’interface HTTPS du connecteur, pas le port LDAP/AD directement sur Internet.
Dans tous les cas, WordWarden doit pouvoir joindre LDAP/AD. Le statut d’établissement académique ne détermine pas le choix : l’infrastructure et la politique réseau, oui.
Authrim Relay : une connexion qui part de l’intérieur
En mode Relay, WordWarden se connecte à Authrim par WebSocket depuis votre réseau. WebSocket garde une connexion ouverte pour permettre aux deux côtés d’échanger des messages.
WordWarden attend sur cette connexion. Lors d’une connexion, Authrim demande : « Vérifiez cet utilisateur. » WordWarden interroge l’annuaire interne et renvoie le résultat par le même chemin.
C’est comme appeler depuis votre organisation et rester en ligne : l’autre personne peut aussi parler. Aucune nouvelle connexion entrante n’est nécessaire à chaque demande.
Le réseau de l’annuaire ne publie donc aucune URL pour ce mode. Cela évite de gérer un nouveau nom public, un certificat et un WAF pour le connecteur. L’autorisation de sortie, la maintenance et la surveillance de la connexion restent nécessaires.
Détail technique : WebSocket et ouverture d’un port entrant
La différence tient à l’initiateur de la connexion. En Direct HTTPS, l’organisation expose un point qu’Authrim peut joindre. Avec Relay, WordWarden ouvre une connexion WebSocket chiffrée (wss) vers Authrim.
Un pare-feu à états ou un NAT suit généralement les connexions ouvertes de l’intérieur et laisse passer leur trafic de retour. WordWarden peut ainsi recevoir des demandes sans publier de port entrant ni configurer de redirection pour de nouvelles connexions externes.
Des ports sont toujours utilisés. Une connexion wss utilise normalement le port TCP 443 à destination. Le pare-feu ou proxy doit autoriser la sortie vers Relay et les connexions WebSocket durables. Tant que la connexion est coupée, aucune demande ne peut arriver par ce chemin ; sa surveillance reste nécessaire.
Réduire les points d’entrée n’élimine pas les requêtes reçues sur la connexion établie. L’authentification du pair et la validation des requêtes restent indispensables.
Une connexion sortante doit aussi être authentifiée. Relay vérifie le connecteur et la destination configurée.
Détail technique : authentification par HMAC
WordWarden répond par HMAC à un défi de courte durée, en signant une chaîne contenant l’identifiant du défi et un nonce. Il vérifie aussi que les identifiants du tenant et du connecteur dans l’URL correspondent à sa configuration.
HMAC est obligatoire dans les trois modes. Relay réduit l’exposition entrante, sans supprimer l’authentification du connecteur ni la gestion des secrets.
Ce qui traverse réellement la frontière
Il faut être précis : le mot de passe peut quitter le réseau interne.
Saisi dans l’interface de connexion, il transite par Authrim. La promesse exacte est : Authrim et WordWarden ne le stockent pas, et non qu’il ne sort jamais.
La documentation le précise : Authrim ne doit ni importer, ni hacher, ni rehacher, ni conserver les mots de passe, y compris leurs empreintes issues d’un système existant.
La réponse est limitée elle aussi
En cas de succès, Authrim reçoit le résultat et les attributs demandés qui figurent dans la liste d’autorisation locale du connecteur. C’est le côté annuaire qui décide ce qu’il transmet, pas le demandeur.
Une modification du seul côté Authrim ne peut donc pas élargir les informations extraites du réseau.
Le mot de passe comme étape de transition
Cette intégration sert la transition.
LDAP/AD reste la référence des mots de passe. Les utilisateurs gardent leur compte habituel pendant l’enregistrement progressif des clés d’accès. Le code e-mail reste un moyen de récupération. Le parcours continue de fonctionner pendant l’évolution de la méthode.
La documentation interdit explicitement d’exporter les empreintes LDAP/AD vers Authrim. Ce serait créer une copie des données d’authentification au lieu d’organiser la transition.
Bêta publique en préparation. Première cible : v0.1.0-beta.1.
Destiné aux pilotes dans des organisations capables d’exploiter un service près de LDAP/AD et de gérer annuaire, réseau, TLS et secrets. Ce n’est pas un annuaire managé.
Nécessite Authrim 0.3.2 ou ultérieur, avec Directory Authentication et Relay activés. La bêta actuelle demande un redémarrage du processus lors d’un changement de configuration.
Copier les données d’authentification ou ouvrir une entrée ne sont pas les seules possibilités.
Vérifier près de l’annuaire et ouvrir la connexion vers l’extérieur permet de proposer une connexion moderne sans copier les empreintes de mots de passe ni publier de point entrant dans le réseau interne.
L’objectif est ensuite le passage aux clés d’accès. L’intégration à l’annuaire fournit l’appui nécessaire pour avancer sans interrompre la connexion des utilisateurs.
Les utilisateurs arrivent en nombre. C’est une bonne nouvelle, mais combien de temps la base actuelle pourra-t-elle les accueillir ? Authrim prépare le stockage des nouveaux comptes en amont, pour que la croissance ne commence pas par un projet de migration.
Ajouter du stockage avant de déplacer les données
Cloudflare D1, utilisé par Authrim, limite la taille d’une base : 500 Mo avec l’offre gratuite, 10 Go avec l’offre payante. À mesure que les utilisateurs et leurs données augmentent, un autre emplacement devient nécessaire.
Authrim peut répartir les comptes entre plusieurs bases dès le départ, sans devoir déplacer tous les comptes existants. Chaque unité de stockage est appelée un shard, ou partition.
Les comptes existants restent en place ; de nouveaux emplacements accueillent les nouveaux comptes. C’est le principe de l’extension du stockage.
Toutes les données ne grandissent pas au même rythme
Authrim sépare les réglages des tenants — clients OAuth et politiques —, les comptes et données personnelles, et les index permettant de retrouver un compte à partir d’une adresse e-mail.
Une hausse du nombre d’utilisateurs n’exige pas d’agrandir toutes les bases ensemble. Comptes et index ont des volumes et des rythmes différents. La capacité est ajoutée là où elle est nécessaire.
Un nouveau compte est affecté à un shard disponible pour son tenant. Les shards sains dont le nombre de comptes est faible par rapport à leur objectif sont privilégiés.
Le critère n’est pas l’occupation du disque, mais le nombre de comptes encore acceptables selon l’objectif configuré. Pour une cible de 100 000 comptes, une marge restante de 20 000 aide à décider quand préparer la suite.
Lorsque la marge devient faible, un shard de réserve est affecté. Le principe vaut pour les shards partagés entre tenants comme pour ceux réservés à un seul tenant.
Tenants en stockage partagé
Tenants en stockage dédié
Stockages partagé et dédié
Dans les configurations partagées, dédiées ou mixtes, les nouveaux shards accueillent les nouveaux comptes. Le niveau d’eau illustre le nombre de comptes affectés, pas l’occupation du disque ni l’instant exact d’ajout. Les séparations représentent l’isolation logique des tenants.
Ce que l’exploitation quotidienne n’exige plus
Une fois l’approvisionnement automatique configuré, l’opérateur n’a plus à créer une base, préparer ses tables et raccorder un nouvel emplacement à chaque hausse des inscriptions. Chaque ajout de capacité n’exige pas non plus un plan de migration des comptes existants.
L’opérateur vérifie l’avancement, les échecs, l’utilisation et les coûts. Il intervient en cas de permissions manquantes ou de limites du service. Avec cette répartition des tâches, Authrim prépare le stockage suivant.
L’espace libre actuel ne suffit pas
Avec 20 000 places restantes, un service gagnant 100 comptes par jour dispose de beaucoup plus de temps qu’un service en gagnant 10 000 par heure.
Authrim estime donc les besoins à partir du rythme récent des inscriptions et des allocations actuelles, pour les comptes comme pour les index. Une tâche s’exécute chaque minute ; les prévisions des comptes sont aussi actualisées après leur affectation.
Les shards en cours de création comptent dans l’estimation, pour éviter que plusieurs processus constatant le même manque créent chacun une base inutile.
De la création à l’utilisation
Quand les réserves ne suffisent plus, Authrim crée des bases D1 via l’API de gestion Cloudflare. Il prépare les tables, configure l’accès des Workers et distribue les emplacements. La base devient disponible pour l’affectation après validation des lectures et écritures.
L’approvisionnement automatique doit être activé, avec des jetons API distincts pour D1 et Workers. S’il ne peut pas s’exécuter automatiquement, l’opérateur poursuit via l’outil de configuration.
L’avancement est conservé. Une panne temporaire permet de reprendre à partir de cet état. Les problèmes de droits ou de limites de ressources nécessitent une intervention avant la reprise.
Si la préparation prend du retard et que les places sont épuisées, les nouvelles inscriptions peuvent devoir réessayer. L’anticipation vise à réduire cette attente.
L’opérateur décide des déplacements
Ajouter de la capacité et déplacer des données sont deux opérations distinctes. Passer un tenant d’un shard partagé à un shard dédié nécessite aussi de copier ses données existantes.
L’opérateur décide de lancer la migration. Après accord, Authrim assure la synchronisation, la vérification et la bascule.
Après accord, les données sont synchronisées et vérifiées avant la bascule. Une étape de cette migration suspend brièvement les écritures.
Le changement actuellement pris en charge va du partagé vers le dédié. Le retour au partagé et le rééquilibrage automatique des comptes existants ne sont pas implémentés.
Supprimer un shard retiré demande également un accord. La croissance ne déclenche pas à elle seule le déplacement ou la suppression des données existantes.
Ce qui a été mesuré
Lors d’un test de juillet 2026 avec 200 000 comptes, Core occupait environ 208 Mo, PII 238 Mo et Lookup 426 Mo. Chacun restait sous 5 % de la limite de 10 Go par base payante. L’utilisation réelle dépend des attributs et index stockés.
L’objectif par défaut est de 100 000 comptes par shard, afin de garder une marge pour préparer le suivant plutôt que de remplir jusqu’à la limite physique.
Authrim est pré-1.0. L’expérience de production prolongée à grande échelle reste à construire. Mesurer le stockage de 200 000 comptes de test n’équivaut pas à exploiter un service utilisé quotidiennement par des millions de personnes.
Moins de migrations à planifier
Un petit service peut commencer avec quelques shards, puis ajouter des emplacements lorsque les inscriptions augmentent. Authrim intègre la préparation et les procédures nécessaires.
Quand les utilisateurs arrivent, préparer un déménagement de base ne devrait pas devenir la première tâche. Réduire ce travail laisse davantage de temps au service lui-même.
Mesure du 30 juillet 2026 sur 200 000 comptes de test. Mo exprimés en unités décimales. Limites D1 : documentation Cloudflare.
Performances
Des charges validées par des tests.
3,500RPSPoints de terminaison liés aux jetons
150connexions / sParcours de connexion OAuth complet
1–4msTemps CPU habituel
0% d’erreursLors des tests
Les tests K6 Cloud couvrent des charges OIDC représentatives. La capacité dépend des requêtes, des limites de l’offre Cloudflare, du stockage et du partitionnement.
Authrim ne facture aucun coût par utilisateur. Le coût d’infrastructure dépend des requêtes, du temps CPU, du stockage et des journaux. Cette estimation Cloudflare est indicative ; ce n’est pas un devis de production.
Utilisateurs actifs par mois50,000
Type de service
HypothèsesConnexion hebdomadaire, 10 % de DAU, session de 7 jours
Gratuit/ mois
Requêtes~1M
Par utilisateurGratuit
Workers : offre gratuite (100 000/jour)(USD)
Estimation fondée sur les tarifs Cloudflare Workers avec un coefficient pour KV, Durable Objects et D1, d’après les usages observés d’Authrim.
À savoir — Infrastructure uniquement. Conformité, supervision, assistance, exploitation, audit de sécurité, bases externes et usage important de R2 ou des archives sont exclus. Le coût réel dépend du déploiement.
Des API pensées pour TypeScript, des SDK JavaScript et une procédure d’installation pour évaluer et développer une infrastructure d’identité en périphérie du réseau.
TypeScriptSDKsInstallation rapide
B
Entreprises
La maîtrise d’un hébergement géré par vos soins : SAML, SCIM, journaux d’audit, séparation des tenants et contrôle du stockage et des journaux. Le renforcement pour la production se poursuit.
SSOSCIMConformité
C
Start-up
Démarrez sur Cloudflare sans frais Authrim par utilisateur, puis ajustez les ressources selon les requêtes, le CPU, le stockage et les journaux réellement mesurés.
Évaluez une plateforme d’identité open source pour Cloudflare Workers. Les protocoles principaux sont implémentés ; le renforcement pour la production est en cours.
