Architecture aux limites claires.
AccountMaker est conçu autour de surfaces d'identité explicites, d'une portée limitée et d'un comportement prévisible.
Vue d'ensemble
AccountMaker fournit l'authentification et l'email lié à l'identité comme un système unique, lié à un domaine vérifié. Chaque capacité est volontairement limitée pour réduire la complexité et la surface d'attaque.
Authentification
Flux OAuth 2.0 et OpenID Connect servis depuis un domaine vérifié.
Email transactionnel
Email déclenché par l'identité envoyé depuis le même domaine que l'authentification.
Email d'identité entrant
Gestion contrôlée d'adresses d'identité génériques comme support@ ou legal@.
Principes d'architecture
Surface d'identité unique
Les utilisateurs interagissent avec un seul domaine pour la connexion et la communication liée à l'identité.
Portée restreinte
Seuls l'authentification et l'email lié à l'identité sont pris en charge.
Limites explicites
Chaque capacité a une responsabilité claire et ne déborde pas sur la logique applicative.
Comportement prévisible
Pas d'automatisation cachée, d'heuristiques ou d'effets de bord transversaux.
Flux d'identité
Vérification du domaine
Un domaine est vérifié avant d'activer tout comportement d'identité côté client.
Demandes d'authentification
Les utilisateurs s'authentifient via des endpoints OAuth ou OpenID Connect servis depuis le domaine vérifié.
Communication transactionnelle
Les emails liés à l'identité proviennent du même domaine et se réfèrent à la même surface d'identité.
Gestion entrante
Les messages envoyés à des adresses liées à l'identité sont reçus et traités sous la même limite de domaine.
Séparation des responsabilités
Logique applicative
Le comportement spécifique du produit, l'UI et les règles métier restent entièrement dans l'application.
Infrastructure d'identité
L'authentification, l'identité email et l'application du domaine sont gérées par AccountMaker.
Communication opérationnelle
Les messages de sécurité et d'identité sont isolés du marketing ou du contenu généré par les utilisateurs.
Non-objectifs explicites
Hébergement d'interface utilisateur
AccountMaker n'héberge pas l'UI de l'application au-delà des flux d'authentification.
Email marketing ou prospection
Le système ne peut pas être utilisé pour des campagnes, promotions ou envois de masse.
Hébergement email général
Pas de boîtes personnelles, de boîtes d'employés, ni d'accès IMAP/POP.
Logique d'autorisation applicative
Les permissions fines du produit restent la responsabilité de l'application.
Considérations opérationnelles
Rayon d'impact limité
La portée restreinte réduit l'impact d'une mauvaise configuration ou d'une défaillance.
Stabilité du domaine
L'identité reste stable même lorsque les fonctionnalités de l'application évoluent.
Comportement auditable
Les actions d'authentification et d'email sont observables et vérifiables.
Où cette architecture convient
For
- Plateformes SaaS en production
- Produits B2B avec des flux sensibles à la sécurité
- Équipes qui valorisent des limites claires de responsabilité
Not for
- Prototypes expérimentaux
- Applications grand public anonymes
- Produits cherchant des plateformes marketing tout-en-un
Une architecture qui sait s'effacer.
AccountMaker se concentre sur l'infrastructure d'identité pour que les équipes produit se concentrent sur le comportement produit.