Account 管理アーキテクチャ

概要

EcAuth では既に B2C / B2B のユーザー管理 が定義されているが、これらは EcAuth を利用する顧客 EC-CUBE サイトのユーザー を扱うものであり、EcAuth サービスそのものの利用者（申込者・組織オーナー）を扱う層は未実装である。

本ドキュメントは、その第三の層である Account（EcAuth 管理者ユーザー） の設計を定義する。Issue #39 の申込 API 実装（Phase D）の前提となる。

ユーザー管理層の位置付け

設計の基本方針

1. Account 用 Organization の二重配置

Account の認証ドメインを 2 つの Organization として本番 DB に同居させ、両方を本番 App Service に配置する。

両方を本番 App Service に同居させる理由は、Azure App Service のステージングスロットや staging App Service がカスタムサブドメインを十分にサポートできず、TenantMiddleware のサブドメイン解決がデフォルトテナントにフォールバックしてしまうため。本番側のカスタムドメイン機能は問題なく複数サブドメインを 1 つの App Service に同居させられる。

さらに本番 App Service は既に *.ec-auth.io のワイルドカード Custom Domain（ecauth-infrastructure/environments/production/main.tf の custom_hostnames = ["*.ec-auth.io"]）とワイルドカード SSL を持つため、accounts / stg-accounts のサブドメインは 個別の DNS / Custom Domain 追加なしに即座に解決される。詳細は DNS / Cloudflare Pages 構成 を参照。

2. 既存 B2B Passkey API の無改修流用

Account 用の認証 API は新規実装せず、既存の /v1/b2b/passkey/* エンドポイントを呼び出す。accounts.ec-auth.io または stg-accounts.ec-auth.io に対してリクエストすれば、既存の TenantMiddleware がサブドメインから tenant_name を抽出し、対応する Organization に解決される。

• B2BPasskeyController — 無改修
• B2BPasskeyService / B2BUserService — 無改修
• B2BUser / B2BPasskeyCredential テーブル — 無改修
• TenantMiddleware — 無改修

3. account テーブルの位置付け

既存の空 account テーブルを「Account の補助情報テーブル」として再定義する。認証情報は B2BUser + B2BPasskeyCredential が保持し、account は次の責務に絞る:

• メールアドレス（EC-CUBE の dtb_member.login_id と同様の位置付け）
• 表示名・確認状態など、認証本体に含まれない補助情報

1 つの Account は 1 つの B2BUser と Subject (UUID) を共有する 1:1 関係とする。

4. account_organization 中間テーブル（N:N）

1 つの Account が複数の顧客 Organization を管理できる。account_organization 中間テーブルで「Account ↔ Organization のロール」を表現する。テナントクエリフィルター対象外（IgnoreQueryFilters で参照）として、Account から自分の管理対象 Org を横断的に引けるようにする。

データモデル

ER 図

erDiagram
    organization ||--o{ b2b_user : "has"
    organization ||--o{ account : "has (accounts / stg-accounts only)"
    organization ||--o{ client : "has"
    b2b_user ||--o{ b2b_passkey_credential : "has"
    b2b_user ||--|| account : "shares subject (accounts / stg-accounts only)"
    account ||--o{ account_organization : "owns"
    organization ||--o{ account_organization : "managed by"
    account ||--o{ magic_login_token : "issues"

    organization {
        int id PK
        string code UK
        string tenant_name
        string name
        bool is_sandbox
    }
    b2b_user {
        int id PK
        string subject UK "UUID"
        string external_id "SHA-256(正規化 email) for Account"
        string user_type "account_owner / admin / staff"
        int organization_id FK
    }
    b2b_passkey_credential {
        int id PK
        string b2b_subject FK
        bytes credential_id UK
        bytes public_key
        uint sign_count
    }
    account {
        int id PK
        string subject UK "= b2b_user.subject"
        string email
        int organization_id FK "= accounts or stg-accounts"
        string display_name
        datetimeoffset email_verified_at
    }
    account_organization {
        string account_subject PK,FK
        int organization_id PK,FK
        string role "owner / admin / member"
        datetimeoffset created_at
    }
    client {
        int id PK
        string client_id UK
        int organization_id FK
        string subject_type "B2C / B2B / Account"
        string allowed_rp_ids
    }
    magic_login_token {
        int id PK
        string account_subject FK "nullable (Account 不在時は null)"
        string requested_email_hash "SHA-256(正規化 email)。レート制限の判定キー"
        string token_hash UK "SHA-256 hash (平文非保存)"
        datetimeoffset expires_at
        datetimeoffset used_at "nullable"
        string requested_ip
        string requested_user_agent
        datetimeoffset created_at
    }
        

Account テーブル拡張仕様

現状の account テーブル（id / email / password / created_at / updated_at）に対し、以下の変更を加える。

EC-CUBE の dtb_member.login_id と同様、Account.email と B2BUser.external_id は同一のメールアドレスに対応づける運用ルールとする（accounts / stg-accounts Org スコープに限る）。ただし B2BUser.external_id は個人情報非保持要件（要件定義 3.2.1）に従い、メールアドレスを正規化（lowercase + trim）したうえで SHA-256 ハッシュ化した値を保持する。したがって両者の関係は B2BUser.external_id == SHA-256(正規化(Account.email)) であり、値そのものは一致しない（Account.email は画面表示・メール送信のため平文を保持）。

ハッシュ化は EcAuth サーバー側で行う（SignupService の account_owner 生成、および B2BPasskeyService の JIT プロビジョニング／external_id 同期／検索の各経路で同一の正規化＋ハッシュ関数を適用する）。EC-CUBE プラグインは従来どおり平文の login_id を送信し、ハッシュ化には関与しない。B2BUser 側の (organization_id, external_id) 複合ユニーク制約は、ハッシュがメールから決定的に導出されるため、ハッシュ化後もそのまま email のユニーク性を担保する。

Account C# モデル

[Table("account")]
public class Account : ISubjectProvider
{
    [Key]
    [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    [Column("id")]
    public int Id { get; set; }

    [Column("subject")]
    [MaxLength(255)]
    [Required]
    public string Subject { get; set; } = string.Empty;  // B2BUser.Subject と一致

    [Column("email")]
    [MaxLength(255)]
    [Required]
    public string Email { get; set; } = string.Empty;

    [Column("organization_id")]
    [Required]
    public int OrganizationId { get; set; }              // accounts / stg-accounts Org

    [Column("display_name")]
    [MaxLength(255)]
    public string? DisplayName { get; set; }

    [Column("email_verified_at")]
    public DateTimeOffset? EmailVerifiedAt { get; set; }

    [Column("created_at")]
    public DateTimeOffset CreatedAt { get; set; } = DateTimeOffset.UtcNow;

    [Column("updated_at")]
    public DateTimeOffset UpdatedAt { get; set; } = DateTimeOffset.UtcNow;

    public Organization? Organization { get; set; }
    public ICollection<AccountOrganization> ManagedOrganizations { get; }
        = new List<AccountOrganization>();
}

AccountOrganization C# モデル

[Table("account_organization")]
public class AccountOrganization
{
    [Column("account_subject")]
    [MaxLength(255)]
    [Required]
    public string AccountSubject { get; set; } = string.Empty;  // Account.Subject FK

    [Column("organization_id")]
    [Required]
    public int OrganizationId { get; set; }                      // 管理対象 Org FK

    [Column("role")]
    [MaxLength(50)]
    [Required]
    public string Role { get; set; } = "owner";                  // owner / admin / member

    [Column("created_at")]
    public DateTimeOffset CreatedAt { get; set; } = DateTimeOffset.UtcNow;

    public Account? Account { get; set; }
    public Organization? Organization { get; set; }
}

主キーは (account_subject, organization_id) の複合キー。Fluent API で HasKey を指定する。

MagicLoginToken C# モデル

パスキー紛失時のリカバリ手段として、メール経由のマジックリンクログインを併設する。常時利用可能な認証手段だが、UI 動線上はメインのパスキーログインフォーム下部の「ログインできない方はこちら」リンクからのみ到達できるセカンダリ動線とする（リテラシーの低いユーザーがパスキー紛失時に離脱しないため）。

[Table("magic_login_token")]
public class MagicLoginToken
{
    [Key]
    [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    [Column("id")]
    public int Id { get; set; }

    [Column("account_subject")]
    [MaxLength(255)]
    public string? AccountSubject { get; set; }                 // Account.Subject FK。Account 不在のリクエストは null

    [Column("requested_email_hash")]
    [MaxLength(64)]
    [Required]
    public string RequestedEmailHash { get; set; } = string.Empty;  // SHA-256(lowercase + trim 済み email)。レート制限の判定キー

    [Column("token_hash")]
    [MaxLength(128)]
    [Required]
    public string TokenHash { get; set; } = string.Empty;       // SHA-256 (Base64URL)、平文は DB に保存しない

    [Column("expires_at")]
    [Required]
    public DateTimeOffset ExpiresAt { get; set; }               // 発行から 10 分

    [Column("used_at")]
    public DateTimeOffset? UsedAt { get; set; }                 // 単発使用後にマーク

    [Column("requested_ip")]
    [MaxLength(45)]
    public string? RequestedIp { get; set; }                    // IPv6 対応 (45 = INET6_ADDRSTRLEN)

    [Column("requested_user_agent")]
    [MaxLength(1000)]
    public string? RequestedUserAgent { get; set; }  // 拡張ブラウザ/in-app browser で 500 超過事例あり

    [Column("created_at")]
    public DateTimeOffset CreatedAt { get; set; } = DateTimeOffset.UtcNow;

    public Account? Account { get; set; }
}

• 平文トークンは DB に保存しない。32 byte URL-safe random をメール送信し、SHA-256 ハッシュのみ token_hash に保存する。
• 有効期限 10 分。発行後 10 分以内にメール内リンクをクリックしないと無効化される。
• 単発使用。used_at が non-null になった行は再利用不可。
• IP / User-Agent ログ。requested_ip / requested_user_agent に記録し、後日の監査・異常検知に使用。

DbContext 設定

// EcAuthDbContext.OnModelCreating に追加

// Account: 所属 Org のテナント（accounts / stg-accounts）のみ参照可能
modelBuilder.Entity<Account>()
    .HasQueryFilter(a => a.Organization != null
        && a.Organization.TenantName == _tenantService.TenantName);

modelBuilder.Entity<Account>()
    .HasAlternateKey(a => a.Subject);

modelBuilder.Entity<Account>()
    .HasOne(a => a.Organization)
    .WithMany()
    .HasForeignKey(a => a.OrganizationId)
    .OnDelete(DeleteBehavior.Restrict);

modelBuilder.Entity<Account>()
    .HasIndex(a => new { a.OrganizationId, a.Email })
    .IsUnique();

// AccountOrganization: テナント横断（クエリフィルター対象外）
modelBuilder.Entity<AccountOrganization>()
    .HasKey(ao => new { ao.AccountSubject, ao.OrganizationId });

modelBuilder.Entity<AccountOrganization>()
    .HasOne(ao => ao.Account)
    .WithMany(a => a.ManagedOrganizations)
    .HasForeignKey(ao => ao.AccountSubject)
    .HasPrincipalKey(a => a.Subject)
    .OnDelete(DeleteBehavior.Cascade);

modelBuilder.Entity<AccountOrganization>()
    .HasOne(ao => ao.Organization)
    .WithMany()
    .HasForeignKey(ao => ao.OrganizationId)
    .OnDelete(DeleteBehavior.Restrict);
// ※ AccountOrganization にはテナントクエリフィルターを設定しない

// MagicLoginToken: テナント横断のレート制限判定を行うため QueryFilter は設定しない
// （Account 不在のリクエストも email_hash で記録されるため）
modelBuilder.Entity<MagicLoginToken>()
    .HasOne(t => t.Account)
    .WithMany()
    .HasForeignKey(t => t.AccountSubject)
    .HasPrincipalKey(a => a.Subject)
    .IsRequired(false)               // Account 不在のリクエストは AccountSubject = null
    .OnDelete(DeleteBehavior.Cascade);

modelBuilder.Entity<MagicLoginToken>()
    .HasIndex(t => t.TokenHash)
    .IsUnique();

modelBuilder.Entity<MagicLoginToken>()
    .HasIndex(t => t.ExpiresAt);   // 期限切れ削除バッチ用

// レート制限判定用の複合インデックス（Redis 不使用、DB ベース実装）
modelBuilder.Entity<MagicLoginToken>()
    .HasIndex(t => new { t.RequestedEmailHash, t.CreatedAt });

modelBuilder.Entity<MagicLoginToken>()
    .HasIndex(t => new { t.RequestedIp, t.CreatedAt });

Client.subject_type カラム追加

TokenController が認可コードを発行する際に発行先 SubjectType を決定するため、Client に種別カラムを追加する。これは将来の B2B SSO 拡張時にも有用である。

// Client.cs
[Column("subject_type")]
[Required]
public SubjectType SubjectType { get; set; } = SubjectType.B2C;

• 既存の B2C 用 Client → SubjectType.B2C（デフォルト）
• EC-CUBE 管理画面用 Client → SubjectType.B2B
• ecauth-admin-console（後述）→ SubjectType.Account

認証フロー

Account 登録フロー（申込時）

sequenceDiagram
    autonumber
    participant U as 申込者
    participant W as ec-auth.io
(Cloudflare Pages)
    participant A as accounts.ec-auth.io
(本番 IdentityProvider)
    participant DB as 本番 EcAuth DB

    U->>W: 申込フォーム入力
(email, organization_name, 本番/テスト URL,
EC プラットフォーム)
    Note over W,A: Cloudflare マネージドチャレンジ（エッジ）を通過
    W->>A: POST /api/signup/request
{email, organization_name, production_site_url?,
test_site_url?, ec_cube_version}
    A->>A: バリデーション（使い捨てメール / URL 片方必須 /
組織コード導出 / code 重複）
    A->>A: 平文トークン生成
SHA-256 ハッシュ計算
    A->>DB: SignupRequest 作成 (confirm_token_hash)
    A-->>U: メール送信 (SendGrid)
確認リンク付き（フロントエンド確認ページ URL）
    U->>W: GET /signup/confirm?token=...
（メールのリンク。状態変更しない）
    W-->>U: 確認ページ表示（「確定」ボタン）
    U->>W: 「確定」操作
    W->>A: POST /api/signup/confirm
{ "token": "..." }
    A->>A: SHA-256(token) 計算 → token_hash 照合
+ 再バリデーション（code 重複 → 409）
    A->>DB: Account 作成 (Subject=UUID)
    A->>DB: B2BUser 作成 (Subject 共有, external_id=SHA-256(email),
user_type="account_owner", org=accounts)
    A->>DB: 顧客 Organization 作成
(入力 URL に応じ 1〜2 件: 本番=is_sandbox false /
テスト=is_sandbox true)
    A->>DB: Client 作成 (作成した Org ごとに 1 件)
    A->>DB: AccountOrganization 作成
(role=owner, Org ごとに 1 行)
    A-->>U: パスキー登録画面へ
    U->>A: POST /v1/b2b/passkey/register/options
(client_id=ecauth-admin-console)
    Note over A: 既存 B2BPasskeyController が処理
tenant=accounts として解決
    A-->>U: 登録オプション返却
    U->>A: POST /v1/b2b/passkey/register/verify
    A->>DB: B2BPasskeyCredential 作成
    A-->>U: 完了 → 管理画面ログインへ
        

Account ログインフロー

sequenceDiagram
    autonumber
    participant U as Account
    participant C as accounts.ec-auth.io
(管理画面 SPA)
    participant A as IdentityProvider
    participant DB as EcAuth DB

    U->>C: アクセス
    C->>A: POST /v1/b2b/passkey/authenticate/options
(client_id=ecauth-admin-console)
    A->>DB: WebAuthnChallenge 作成
    A-->>C: 認証オプション返却
    C->>U: WebAuthn API 呼び出し
    U-->>C: 認証応答 (assertion)
    C->>A: POST /v1/b2b/passkey/authenticate/verify
    A->>DB: 署名検証 / SignCount 更新
    A->>DB: AuthorizationCode 発行
(SubjectType=Account)
    A-->>C: redirect_uri?code=...
    C->>A: POST /v1/token (authorization_code)
    A->>DB: AccountOrganization 引き当て
    A-->>C: AccessToken + IDToken
(claims: managed_orgs=[...], role=...)
    Note over C: アクセストークンで管理画面 API へ
        

マジックリンクログインフロー（パスキー不可時の代替動線）

パスキー紛失・OS 再インストール・別デバイス利用などでパスキー認証が使えなくなったユーザー向けに、メール経由のマジックリンクログインを提供する。機能としては常時利用可能だが、UI 動線上はパスキーログインフォーム下部の「ログインできない方はこちら」リンクからのみ到達できるセカンダリ動線とする。これは Yahoo Japan / メルカリの運用方針に倣ったハイブリッド型（通常はパスキー、リカバリ動線は常時開いている）である。

sequenceDiagram
    autonumber
    participant U as Account
    participant F as フロント (Cloudflare Pages)
ec-auth.io
    participant A as IdentityProvider
(accounts.ec-auth.io)
    participant DB as EcAuth DB
    participant M as メール (SendGrid)
    participant C as 管理コンソール
(OAuth クライアント)

    Note over U,F: メイン UI はパスキー認証。
「ログインできない方はこちら」からマジックリンク要求へ
    U->>F: マジックリンク要求画面でメアド入力
    F->>A: POST /api/account/magic-link/request
{email}（クロスオリジン）
    A->>DB: Account 検索 (email)
    Note over A: Email enumeration 対策で
該当なしでも同じレスポンス
    A->>A: トークン生成 (32 byte URL-safe random)
SHA-256 ハッシュ計算
    A->>DB: MagicLoginToken 作成
(token_hash, expires_at=now+10min,
requested_ip, requested_user_agent)
    A->>M: SendGrid でメール送信
(本文に {MagicLink:BaseUrl}/signin/magic-link?token=... リンク)
    A-->>F: 200 OK (常に同じレスポンス)
    F-->>U: 「メールを送信しました」表示

    U->>F: メール内リンクをクリック
GET /signin/magic-link?token=...
(フロント＝Cloudflare Pages、状態変更なし)
    Note over F: メールスキャナの先読みで誤消費されないよう
GET は safe。ユーザー操作で初めて消費する
    U->>F: 「ログイン」操作
    F->>A: POST /api/account/magic-link/verify
{token}（クロスオリジン）
    A->>A: SHA-256(token) 計算
    A->>DB: Compare-And-Set: token_hash 一致かつ used_at IS NULL の行を
used_at=now に原子的 UPDATE（影響行数1で成功）
    A->>DB: AuthorizationCode 発行
(SubjectType=Account, Subject=Account.Subject)
    A-->>F: { location: redirect_uri?code=... }
    F->>C: redirect_uri?code=... へ遷移
    C->>A: POST /v1/token (authorization_code)
    A-->>C: AccessToken + IDToken
    Note over C: パスキー未登録時は登録誘導バナー表示
（強制はしない）
        

マジックリンクエンドポイント

POST /api/account/magic-link/request
{
  "email": "owner@example.jp"
}

// Response (常に同じ。Account の存在有無を漏らさない)
HTTP 200
{
  "message": "メールアドレスが登録されている場合、ログインリンクをお送りしました。"
}

// --- フロントの /signin/magic-link ページがユーザー操作で発行 ---
POST /api/account/magic-link/verify
{
  "token": "<メールリンクの token>"
}

// Response: 認可コードを付与したクライアントのリダイレクト先
HTTP 200
{
  "location": "https://accounts.ec-auth.io/auth/callback?code=..."
}

TokenController での SubjectType.Account 対応

現状 TokenController.cs:314 に「Account 等のサポートされていない SubjectType」コメントがある分岐を有効化する。

// TokenController で SubjectType.Account 分岐を追加
switch (authCode.SubjectType)
{
    case SubjectType.B2C:
        // 既存 EcAuthUser からトークン発行
        break;
    case SubjectType.B2B:
        // 既存 B2BUser からトークン発行
        break;
    case SubjectType.Account:
        var account = await _context.Accounts
            .FirstOrDefaultAsync(a => a.Subject == authCode.Subject);
        var managedOrgs = await _context.AccountOrganizations
            .IgnoreQueryFilters()
            .Where(ao => ao.AccountSubject == authCode.Subject)
            .Select(ao => new { ao.OrganizationId, ao.Role })
            .ToListAsync();
        return await _tokenService.IssueAccountTokenAsync(account, managedOrgs);
}

申込 API 設計（Phase D）

Issue #39 Phase D の申込フローを Account + Organization 自動作成として実装する。

エンドポイント

これらの API は accounts.ec-auth.io と stg-accounts.ec-auth.io の両方に露出する。サブドメインに応じて配下に作られる Account / Organization は自動的に対応するテナント（accounts or stg-accounts）にスコープされる。申込フローの E2E 検証は、本番 stg-accounts への直接実行ではなく、PR-CI のローカルスタック（accounts テナント + mailpit）で実メール経路ごと検証する（下記「Account E2E 検証戦略」参照）。

メール確認フロー（フロントエンド仲介 + POST 確定）

メール確認は API を直接叩かず、フロントエンドの確認ページを経由する設計を採用する。

1. 確認リンクは GET でフロントエンドの確認ページを指す。メール本文のリンクは https://ec-auth.io/signup/confirm?token=... のようなフロントエンド（Cloudflare Pages）の確認ページ URL であり、API（/api/signup/confirm）を直接叩かない。この GET は状態を変更しない（safe / 冪等）。確認ページは申込フォームと同じ Cloudflare Pages サイトから配信され、accounts.ec-auth.io / stg-accounts.ec-auth.io（B2B パスキー org 用テナント = API のホスト）とは別オリジンである。
2. 確認ページがトークンを抽出し、ユーザーの「確定」操作で POST する。確認ページがクエリから token を取り出し、ユーザーが画面上で「確定」を行ったときに POST /api/signup/confirm（ボディは { "token": "..." } の JSON）を発行して、Account / Organization の作成を確定する。

申込リクエスト例

POST /api/signup/request
{
  "email": "owner@example.jp",
  "organization_name": "サンプル株式会社",
  "contact_name": "山田 太郎",
  "production_site_url": "https://example.jp",
  "test_site_url": "https://test.example.jp",
  "ec_cube_version": "4"
}

production_site_url と test_site_url はいずれか一方が必須（本番未構築の申込者はテストサイトのみで申し込める）。contact_name は任意。ec_cube_version は "4" / "2" / "other"。

申込リクエストのバリデーション

POST /api/signup/request はリクエスト時点で以下のバリデーションを実行し、エラーがあれば HTTP 422 Unprocessable Entity を返す。POST /api/signup/confirm でも Race Condition 対策として同じバリデーションを再実行し、申込から confirm の間に他の申込で code が確定した場合は HTTP 409 Conflict を返す。

HTTP 422 Unprocessable Entity
{
  "error": "organization_already_exists",
  "error_description": "このドメインは既に EcAuth に登録されています。別のサイト URL でお申し込みください。",
  "field": "production_site_url"
}

confirm 後に作成されるレコード

• Account: email=owner@example.jp, subject=UUID, organization_id=accounts または stg-accounts の id
• B2BUser: subject=Account.Subject, external_id=SHA-256("owner@example.jp")（正規化後ハッシュ。平文メールは保持しない）, user_type="account_owner", organization_id=accounts または stg-accounts の id
• Organization（本番、production_site_url 指定時）: code=example-jp, is_sandbox=false
• Organization（テスト、test_site_url 指定時）: is_sandbox=true
• Client（作成した Org ごとに 1 件）: allowed_rp_ids に各サイトドメインを設定
• AccountOrganization（作成した Org ごとに 1 行）: role=owner

作成される顧客 Organization は入力された URL に応じて 1〜2 件（本番のみ／テストのみ／両方）。本番・テストが同一ドメインの場合は本番のみ。これらは 1 つの DB トランザクション内で原子的に作成する。途中で失敗した場合はロールバックし、再申込を許可する。

ボット対策・同意取得・アクセシビリティ

• ボット対策: accounts.ec-auth.io は Cloudflare proxy 配下のため、/api/signup/* に Cloudflare マネージドチャレンジ（Managed Challenge）をエッジ（WAF / Bot ルール）で適用する。Turnstile ウィジェットの埋め込みやアプリ側の siteverify 実装は不要で、疑わしいリクエストのみエッジでチャレンジされる（正規ユーザーには基本不可視）。ルール設定は Phase E（インフラ）で行う。
• 同意取得: 申込フォームの送信（「無料ではじめる」）をもって、利用規約・プライバシーポリシー・Cookie ポリシーへの暗黙同意とみなす。同意した各ポリシーのバージョンを SignupRequest に記録する。
• アクセシビリティ: 申込フォーム（ecauth-website 側）は WCAG 2.2 AA 準拠（インラインバリデーション、可視ラベル、aria-invalid / role="alert" / aria-describedby、autocomplete / inputmode）。
• 課金: 申込時はカード情報・請求先を取得しない（フリーミアム無料開始）。将来の機能追加で無料枠を超えた場合のみ、別途クレジットカード決済（Square 基盤）の請求フローを案内する。

テナント解決とホスト設計

ホスト名割り当て

静的サイト（申込ページ）と認証 API でホスト名を分離する。これは現行 TenantMiddleware の「サブドメイン先頭セグメント → tenant_name」ロジックを無改修で活用するための設計である。

DNS / Cloudflare Pages 構成

ec-auth.io               CNAME → ecauth-website.pages.dev    (Cloudflare Pages)
www.ec-auth.io           CNAME → ecauth-website.pages.dev    (Cloudflare Pages)
*.ec-auth.io             CNAME → <本番 EcAuth Azure Web App>  (既存ワイルドカード)
  ├─ accounts.ec-auth.io       (ワイルドカード経由で解決)
  ├─ stg-accounts.ec-auth.io   (ワイルドカード経由で解決)
  └─ <tenant>.ec-auth.io       (各顧客 Org の tenant_name もワイルドカード経由で解決)

例外として api.ec-auth.io（Platform API 用）のような apex 直下のホストは個別の azurerm_app_service_custom_hostname_binding として production/main.tf に明示登録されているが、これは Account 管理ドメインの追加で再現する必要はない（accounts / stg-accounts はサブドメイン形式のためワイルドカードで吸収される）。

パスキー RP ID 設計

本番用 Client（ecauth-admin-console）と stg-accounts 用 Client それぞれに AllowedRpIds を設定する:

RP ID を ec-auth.io（eTLD+1）にすると accounts と stg-accounts でパスキー credential が共有されてしまうため、RP ID はサブドメイン単位で分離する。これにより本番 Account のパスキーが誤って stg-accounts 検証で使えないようガードできる。

is_sandbox の取り扱い

Organization.is_sandbox は 「EcAuth 本番 DB 内で、EC-CUBE 顧客側のテスト店舗 Organization を本番店舗 Organization と区別する」ためのフラグである。試用期間や課金状態の表現には使わない（必要なら別カラムを設ける）。

3 層のテスト/本番分離

各 Organization の is_sandbox 値

• accounts Org → false（実運用の認証ドメイン）
• stg-accounts Org → false（EcAuth 開発チームの検証用だが、認証品質は production スペックなので sandbox 扱いではない）
• 申込で作成される顧客 Org（本番サイト = production_site_url）→ false
• 申込で作成される顧客 Org（テストサイト = test_site_url）→ true

顧客側 staging 店舗（staging.example.jp）の認証は 本番 accounts.ec-auth.io 経由で行う（顧客側に EcAuth staging エンドポイントは公開しない）。顧客の「本番店舗 / staging 店舗」の区別は、本番 accounts Org 配下に is_sandbox=true の子 Org として保持する。

B2B SSO 拡張余地

Account の認証は当面パスキーのみで提供するが、将来的に Azure Entra ID / Google Workspace 等の B2B SSO を追加する余地を残す。

B2C ではなく B2B SSO を採用する理由

• Account の利用者は組織オーナーであり、企業 IdP（Entra ID 等）からの SSO ログインが自然
• B2C フェデレーション（EcAuthUser + ExternalIdpMapping）はエンドユーザー向け JIT プロビジョニング設計のため、組織オーナーには不適
• EC-CUBE 管理者の B2B SSO 化（要件定義 Phase 4）と同一機構を共有可能

将来追加するもの（本フェーズでは実装しない）

-- 新規テーブル（Phase 4 想定）
CREATE TABLE b2b_external_idp_mapping (
    id                INT IDENTITY PRIMARY KEY,
    b2b_subject       NVARCHAR(255) NOT NULL,    -- FK → b2b_user.subject
    external_provider NVARCHAR(100) NOT NULL,    -- azure_entra_id / google_workspace / ...
    external_subject  NVARCHAR(255) NOT NULL,
    created_at        DATETIMEOFFSET NOT NULL,
    CONSTRAINT UQ_b2b_external_idp UNIQUE (external_provider, external_subject)
);

このテーブルが追加されれば、Account も同じ仕組みで Entra ID 等を経由した SSO ログインが可能になる（accounts / stg-accounts Org の B2BUser に対する SSO 連携として）。

現フェーズで矛盾を生まないための準備

1. Client.subject_type カラム導入により、AuthorizationCallback が将来 B2C / B2B / Account を分岐させる責務の置き場所を確立
2. SubjectType.Account のトークン発行経路を TokenController に明示
3. ExternalIdpMapping を B2BUser に後付け拡張せず、新規 b2b_external_idp_mapping を追加する方針を明記（既存テーブル改修を避ける）

マイグレーション計画

必要なマイグレーション

1. UpdateAccountTable
   • password カラム削除
   • subject, organization_id, display_name, email_verified_at カラム追加
   • (organization_id, email) 複合ユニークインデックス
   • subject ユニークインデックス（Alternate Key）
   • FK: account.organization_id → organization.id
2. AddAccountOrganizationTable
   • account_organization テーブル新規作成
   • 主キー: (account_subject, organization_id)
   • FK: account_subject → account.subject（Cascade）、organization_id → organization.id（Restrict）
3. AddSubjectTypeToClient
   • client.subject_type カラム追加（デフォルト B2C=0）
   • 既存 B2B 用 Client は別途 SQL で B2B=1 に更新
4. SeedAccountsOrganizations
   • accounts Organization レコード投入
   • stg-accounts Organization レコード投入
   • ecauth-admin-console Client 投入（accounts Org, subject_type=Account, allowed_rp_ids=["accounts.ec-auth.io"]）
   • ecauth-admin-console-stg Client 投入（stg-accounts Org, subject_type=Account, allowed_rp_ids=["stg-accounts.ec-auth.io"]）
5. AddMagicLoginTokenTable
   • magic_login_token テーブル新規作成
   • 主キー: id（Identity）
   • カラム: account_subject（nullable, FK）、requested_email_hash（NOT NULL, 64 chars）、token_hash、expires_at、used_at、requested_ip、requested_user_agent（1000 chars）、created_at
   • token_hash ユニークインデックス
   • expires_at インデックス（期限切れ削除バッチ用）
   • (requested_email_hash, created_at) 複合インデックス（レート制限判定用、Redis 不使用）
   • (requested_ip, created_at) 複合インデックス（IP レート制限判定用）
   • FK: account_subject → account.subject（OnDelete=Cascade、ただし account_subject は nullable）

Seeder と環境変数

OrganizationClientSeeder を拡張、または専用 AccountsOrganizationSeeder を新設して accounts / stg-accounts の 2 Org とそれぞれの Client を投入する。1Password の項目構成は ecauth-production-app に以下を追加:

# 本番 accounts Org
ACCOUNTS_CLIENT_ID=ecauth-admin-console
ACCOUNTS_CLIENT_SECRET=<1Password 管理>
ACCOUNTS_ALLOWED_RP_IDS=accounts.ec-auth.io
ACCOUNTS_REDIRECT_URI=https://accounts.ec-auth.io/auth/callback

# 開発チーム検証用 stg-accounts Org
STG_ACCOUNTS_CLIENT_ID=ecauth-admin-console-stg
STG_ACCOUNTS_CLIENT_SECRET=<1Password 管理>
STG_ACCOUNTS_ALLOWED_RP_IDS=stg-accounts.ec-auth.io
STG_ACCOUNTS_REDIRECT_URI=https://stg-accounts.ec-auth.io/auth/callback

環境変数の配線ルールは リポジトリガイド の通り 4 箇所すべて（.env.dev.tpl / .env.staging.tpl / GitHub Actions / Terraform app_settings）に追加する。本番 Terraform app_settings のみに設定し、staging Terraform には設定しない（staging EcAuth App Service では Account 機能を扱わないため）。

Account E2E 検証戦略（mailpit ベース）

申込フローとマジックリンクログインは、確認トークン / ログイントークンが メール本文にしか存在しない（DB には SHA-256 ハッシュのみ保存）。このため E2E でフローを完走するには メール本文からトークンを取得する手段が必須となる。当初計画では本番 stg-accounts に対して直接 Playwright を走らせる想定だったが、本番では SendGrid が実 inbox にメールを送るため CI 内でトークンを取得できず、フローを完結できなかった。

これを解決するため、検証は PR-CI のローカルスタックに mailpit（SMTP 受信 + REST API のメールテストツール）を組み込み、実メール経路を丸ごと検証する方式に再構成する。

検証フロー

1. ローカルスタック（accounts テナント + SQL Server + mailpit）を起動。
2. 申込: POST /api/signup/request → アプリが確認メールを mailpit へ送信。
3. テストが mailpit REST API（GET /api/v1/messages → GET /api/v1/message/{id}）で本文を取得し、確認 URL からトークンを抽出。
4. POST /api/signup/confirm でトークンを検証 → パスキー登録（既存 B2B 仮想認証器を流用）→ ログイン → トークン発行 → managed_orgs claim を検証。
5. マジックリンク: POST /api/account/magic-link/request → mailpit からリンク抽出 → POST /api/account/magic-link/verify → 認可コード → トークン。second-use / expired / レート制限の異常系も検証。
6. run ごとに UUID でメールアドレス / subject を一意化（冪等化）、DELETE /api/v1/messages で後処理。

検証環境の役割分担

セキュリティと運用上の注意

本番 DB 内に staging 検証用 Org が同居することの運用注意

Account 削除時の挙動

• Account 削除時、対応する B2BUser も削除（Subject 共有のため整合性を保つ）
• AccountOrganization は Cascade で自動削除
• 管理対象 Organization 本体は 削除しない（owner 1 件削除で顧客サイトが消えると事故になる）
• 最後の owner Account を削除しようとした場合は API エラーとする（権限移譲を強制）

Account 管理画面の CSRF / CORS

• 申込 API（/api/signup/*）は ec-auth.io / www.ec-auth.io からの CORS のみ許可
• 管理画面 API（/v1/account/* 等、Phase E 以降）は accounts.ec-auth.io / stg-accounts.ec-auth.io のみ許可
• SubjectType.Account の AccessToken でないと管理画面 API は呼び出せない
• パスキー RP ID 分離（accounts.ec-auth.io / stg-accounts.ec-auth.io）により、本番 credential が stg-accounts で使用不可

マジックリンクのセキュリティ要件

権限境界

未決事項 / TODO

1. 招待フロー: owner が他 Account を招待する API の設計（Phase E 以降）
2. Account 課金プラン: accounts Org に紐づく課金エンティティの設計（別ドキュメント化予定）。stg-accounts 配下は除外
3. 監査ログ: Account の操作ログをどこに保存するか（既存 AccessToken 監査と統合するか別系統か）
4. EcAuth 自身の管理者（superadmin）: EcAuth 運営者が顧客 Account をサポート目的で代行操作する必要があるか。必要なら account.role=superadmin 等の特別フラグが必要
5. stg-accounts のデータクリーンアップ運用: 自動削除スクリプトの設計（cron + Azure Functions 等）

関連ドキュメント

• ユーザー管理アーキテクチャ（B2C / B2B 統合設計）
• B2B パスキー認証アーキテクチャ
• 要件定義
• Issue #39: EcAuth 紹介・申込 Web サイト構築
• ドメインアーキテクチャ
• シークレット管理（1Password 配線）