概要
AccountMakerは、認証とアイデンティティ関連のメールを単一のシステムとして提供し、検証済みドメインに紐づけます。各機能のスコープを意図的に狭くすることで、複雑さと攻撃面を減らします。
認証
検証済みドメインから提供される OAuth 2.0 と OpenID Connect のフロー。
トランザクションメール
認証と同じドメインから送信されるアイデンティティ起点のメール。
アイデンティティ受信メール
support@ や legal@ などの一般的なアイデンティティアドレスの制御された処理。
アーキテクチャの原則
単一のアイデンティティ面
ユーザーはログインとアイデンティティ関連の通信を1つのドメインで行います。
限定されたスコープ
認証とアイデンティティ関連メールのみをサポートします。
明示的な境界
各機能は明確な責務を持ち、アプリケーションロジックに踏み込みません。
予測可能な挙動
隠れた自動化やヒューリスティクス、横断的な副作用はありません。
アイデンティティの流れ
ドメイン検証
顧客向けのアイデンティティ挙動を有効化する前に、ドメインを検証します。
認証リクエスト
ユーザーは検証済みドメインから提供される OAuth または OpenID Connect のエンドポイントで認証します。
トランザクション通信
アイデンティティ起点のメールは同じドメインから送られ、同じアイデンティティ面を参照します。
受信処理
アイデンティティ関連のアドレスに送られたメッセージは、同一ドメイン境界で受信・処理されます。
関心の分離
アプリケーションロジック
製品固有の挙動、UI、ビジネスルールはすべてアプリケーション側に残します。
アイデンティティ基盤
認証、メールのアイデンティティ、ドメインの強制は AccountMaker が担います。
運用コミュニケーション
セキュリティやアイデンティティ関連のメッセージは、マーケティングやユーザー生成コンテンツから分離されます。
明確な非目標
UIホスティング
AccountMakerは認証フロー以外のアプリケーションUIをホストしません。
マーケティングやアウトリーチのメール
キャンペーン、プロモーション、バルク送信には利用できません。
一般的なメールホスティング
個人用受信箱、社員用メールボックス、IMAP/POP アクセスは提供しません。
アプリケーションの認可ロジック
細かな権限管理はアプリケーション側の責任です。
運用上の考慮点
影響範囲の限定
スコープを狭めることで、設定ミスや障害の影響を抑えます。
ドメインの安定性
アプリの機能が変わっても、アイデンティティは安定して保たれます。
監査可能な挙動
認証とメールの操作は観測可能で、レビューできます。
このアーキテクチャが合う領域
For
- 本番SaaSプラットフォーム
- セキュリティに敏感なワークフローを持つB2B製品
- 明確な責任境界を重視するチーム
Not for
- 実験的なプロトタイプ
- 匿名の一般消費者向けアプリ
- オールインワンのマーケティング基盤を求める製品