AccountMaker.com

アカウント中心インフラ

アカウント中心の認証・アイデンティティ・メール基盤。

OAuth クライアントを作成し、ユーザーをアカウントとメンバーシップで整理し、検証済みドメインと観測可能なイベントでトランザクションメールを配信します。

プラットフォーム図
クライアントアプリ
   │
   ▼
Accountmaker
   ├─ OAuth + OIDC
   ├─ アカウント + メンバーシップ
   ├─ メール + ドメイン
   └─ Webhook + イベント
          

多くの SaaS プラットフォームは同じアイデンティティ基盤を作り直しています。

  • 認証はログインとトークンで止まる。
  • アカウントロジックが製品ごとに再実装される。
  • メールは別スタックにある。
  • Webhook の失敗が見えない。
  • 所有権と権限がずれる。

Accountmaker が変えること

  • 認証・アカウント・メール・イベントを一つのシステムで。
  • 明確なアカウントメンバーシップとロール。
  • ドメイン検証と到達性チェック。
  • メールと Webhook のイベント配信を可観測に。

標準

OAuth 2.0 + OpenID Connect

明確なスコープと予測可能なトークンで標準フローを利用。

スコープ

アカウント優先の権限

アカウントとメンバーシップは派生ではなく第一級プリミティブ。

可視性

可観測イベント

Webhook とメール配信イベントは第一級で監査可能。

仕組み

  1. 1. OAuth クライアントを設定

    リダイレクト URI、スコープ、トークン有効期限を定義。

  2. 2. アカウントとメンバーシップを作成

    所有権、ロール、アカウント権限をモデル化。

  3. 3. メールと Webhook を設定

    ドメインを検証し配信イベントを監視。

証明

アカウントスコープのプリミティブ

すべてのトークン、メールID、Webhook配信はアカウントとメンバーシップロールに紐づきます。

POST /oauth/clients
POST /accounts
POST /accounts/{account_id}/memberships

Accountmaker がしないこと

  • アプリの UI を置き換えない。
  • OAuth やトークンの挙動を隠さない。
  • マーケティングキャンペーンを送らない。

統合の準備

まずはドキュメントから始め、数分でクライアントとアカウントを作成できます。