EcAuth 要件定義書

1. プロジェクト概要

1.1 背景

EC-CUBEは技術リテラシーの低いユーザーに多く利用されているが、開発の煩雑なソーシャルログインやパスキーの導入実績が乏しい。Eコマースという個人情報やクレジットカード決済など、セキュリティが最重要視される環境にもかかわらず、多くのサイトはパスワード認証のみという現状がある。

特に管理画面においては、フィッシング攻撃による管理者アカウント乗っ取りのリスクが高く、店舗全体のセキュリティに影響を及ぼす可能性がある。

1.2 目的

EcAuthは以下の2層構造で認証サービスを提供する：

EC-CUBE に接続するためのプラグイン（無料）を提供することにより、パスキーやソーシャルログインの導入を促進する。

1.3 プロジェクトスコープ

• B2Bパスキー認証サービスの開発（WebAuthn/FIDO2）
• OpenID Connectに基づくIDフェデレーションサービスの開発
• EC-CUBE用接続プラグインの開発
• 将来的なAPI公開による他サービスへの展開
• 将来的なマルチプラットフォーム展開（WordPress / WooCommerce、Magento等）

2. 機能要件

2.1 認証機能

2.1.1 OpenID Connect実装

• 対応フロー: Authorization Code Flow
• 対応スコープ: openid, profile, email, phone, address, b2b
• 提供クレーム: RFC 7519 Section 4.1に準拠
• PKCE対応: 必須
• トークン暗号化: RSA 2048bit署名

2.1.2 外部IdP連携

対応予定プロバイダー:

• B2C向け: Google, Facebook, LINE, Yahoo Japan, Apple, Microsoft
• B2B向け: Azure Entra ID, Google Workspace

連携方式:

• プロトコル: OpenID Connect
• トークン有効期限: 外部IdPに準拠
• ユーザーマッピング: EcAuthユーザーテーブルに外部IdPのsubjectを1:N紐付け

2.1.3 パスキー対応

WebAuthn/FIDO2に準拠したパスキー認証を実装する。

2.1.3.1 B2Bパスキー（管理画面用）

• 対象: EC-CUBE管理者（店舗オーナー、スタッフ）
• 価格: フリーミアム（5ユーザーまで無料）
• データモデル:
  • B2BUser: 管理者ユーザー情報
  • B2BPasskeyCredential: パスキー認証情報（公開鍵、SignCount等）
  • WebAuthnChallenge: 認証チャレンジ（5分有効）
• APIエンドポイント: /v1/b2b/passkey/*
• 本人確認: パスキー登録時はEC-CUBEプラグイン側でパスワード再入力を要求
• RP ID: EC-CUBEサイトのドメインを使用（店舗ごとに異なる）
• フロントUI: EC-CUBEプラグイン側で実装（Twigテンプレートでカスタマイズ可能）

2.1.3.2 B2Cパスキー（フロント用）

• 対象: ECサイトのエンドユーザー（顧客）
• 価格: MAU課金
• 実装時期: Phase 2（B2Bパスキー完了後）
• 本人確認: 仮会員登録機能（メールアドレス確認）で担保

2.2 マルチテナント機能

2.2.1 テナント管理

• Organizationモデルによるテナント管理
• 各EC-CUBEサイトが1つのOrganizationに対応
• 論理分離によるテナント間データ分離

2.2.2 クライアント管理

• Organization配下でのClient管理
• RedirectURI管理
• Client IDおよびClient Secretの発行
• 許可RP ID（パスキー用ドメイン）の管理

2.3 ユーザー管理

2.3.1 B2Cエンドユーザー管理

• 個人情報非保持設計（ハッシュ化したメールアドレスのみ保持）
• 外部IdPのsubjectとの紐付け管理
• EC-CUBEのdtb_customerテーブルとUUID文字列による連携
• データモデル: EcAuthUser, ExternalIdpMapping

2.3.2 B2Bユーザー管理

• EC-CUBE管理者向けのパスキー認証
• EC-CUBEのdtb_memberテーブルとの連携
• Organization単位でのユーザー分離
• データモデル: B2BUser, B2BPasskeyCredential, WebAuthnChallenge
• 将来的な企業SSO（Azure Entra ID等）への拡張を考慮

2.3.3 EcAuth管理者アカウント

• Accountテーブルによる管理者認証（SSO非対象）

2.4 EC-CUBE連携

2.4.1 プラグイン提供

• EC-CUBE 2系対応プラグイン
• EC-CUBE 4系対応プラグイン
• プラグイン自体は無料提供
• 1プラグインで以下の全機能を提供（EC-CUBEバージョンごとに1プラグイン）:
  • 管理画面パスキー認証（B2B）
  • フロント画面パスキー認証（B2C）
  • フロント画面外部IdPフェデレーション
  • 企業SSO（Azure Entra ID, Google Workspace）
  • 将来構想: 企業間SAML連携
• 機能の有効化/無効化は設定画面で切り替え可能
• 未契約・未有効化の機能はグレーアウト表示+契約案内を表示
• 有料機能の利用制限はEcAuth側で管理

2.4.2 管理画面パスキー連携

• 管理画面ログイン画面へのパスキーボタン追加
• パスキー管理画面（登録・削除）
• 登録完了通知メール（推奨）

2.4.3 セッション管理

• EcAuthトークン有効期限切れ時のEC-CUBE側ログアウト
• 厳密な整合性は考慮しない設計

3. 非機能要件

3.1 性能要件

• ピーク時処理能力: 100クライアント/秒
• レスポンスタイム: 500ms以内

3.2 セキュリティ要件

3.2.1 データ保護

• 個人情報非保持設計
• トークン内個人情報の非保存またはハッシュ化保存
• RSA 2048bit署名によるトークン保護

3.2.2 パスキーセキュリティ

• チャレンジの一意性（毎回ランダム生成、5分で期限切れ）
• SignCount検証によるリプレイ攻撃防止
• RP ID（ドメイン）検証によるフィッシング防止
• User Verification: preferred以上を推奨

3.2.3 コンプライアンス

• 日本の個人情報保護法準拠（必須）
• GDPR対応（将来対応）
• OWASP ZAPによるペネトレーションテスト（低優先度）

3.3 可用性要件

• Azure SQL Databaseのバックアップ・リカバリ機能に準拠

3.4 運用性要件

• 初期段階ではDB直接操作による管理
• 将来的に管理画面実装予定

4. システム構成

4.1 技術スタック

• バックエンド: .NET 9.0, ASP.NET Core
• データベース: Microsoft SQL Server 2022, Azure SQL Database
• WebAuthn: Fido2.NetLib
• フロントエンド: React（将来）
• EC-CUBEプラグイン: PHP, JavaScript, PostgreSQL, MySQL
• インフラ: Azure Web Apps, Docker

4.2 プロジェクト構成

• IdentityProvider: メインAPIプロジェクト
• MockOpenIdProvider: E2Eテスト用モックIdP
• IdpUtilities: 共通ユーティリティライブラリ
• ConsoleApp: CLIユーティリティ（RSA鍵生成等）
• E2ETests: Playwrightによるテスト
• 各種ユニットテスト

5. ビジネス要件

5.1 料金体系

5.1.1 B2Bパスキー（管理画面）

5.1.2 B2Cフロント認証（MAU課金）

5.2 課金・利用状況管理

• 将来的にダッシュボード実装予定
• クレジットカード決済対応（決済会社未定）

6. リリース計画

6.1 リリースロードマップ

1. Phase 1 (MVP) — 管理画面パスキー EC-CUBE 4系優先 / 2系対応、5ユーザーまで無料
2. Phase 2 — フロントパスキー ECサイトフロントの B2C パスキー認証、MAU 課金
3. Phase 3 — 外部 IdP 連携 (ソーシャルログイン) Google / LINE / Facebook 等、MAU 課金
4. Phase 4 — 企業 SSO Azure Entra ID / Google Workspace、B2B 有料プラン
5. Phase 5 — マルチプラットフォーム展開 WordPress / Magento 等、フェデレーションハブ強化

Phase 1（MVP）: 管理画面パスキー

• EC-CUBE管理画面へのパスキー認証プラグイン
• 5ユーザーまで無料、6ユーザー以上は有料（100円/ユーザー/月）
• リリース当初は課金システム未構築のため全ユーザー無料の可能性あり
• 対応バージョン: EC-CUBE 4系（優先）、EC-CUBE 2系

Phase 2: フロントパスキー

• ECサイトフロントへのパスキー認証
• MAU課金

Phase 3: 外部IdP連携（ソーシャルログイン）

• Google, LINE, Facebook対応
• MAU課金

Phase 4: 企業SSO

• Azure Entra ID, Google Workspace連携
• B2B有料プラン

Phase 5: マルチプラットフォーム展開

• EC-CUBE以外のECプラットフォーム・CMSへの対応
• EcAuthのフェデレーションハブとしてのポジション強化

対応プラットフォーム候補と実現可能性:

実現可能性の根拠:

• EcAuthのB2BパスキーAPIはRESTベースであり、特定CMS固有の依存がない
• B2Cフェデレーションは標準的なOAuth2/OIDC Authorization Code Flowに準拠しており、OIDCクライアントを実装可能な任意のプラットフォームから利用可能
• WebAuthn JavaScript API（navigator.credentials.*）の呼び出しはプラグイン側で実装するため、フロントエンドのカスタマイズが可能なプラットフォームであれば対応可能
• SaaSプラットフォーム（Shopify等）は各社の制約に依存するため、機能ごとに実現可否が異なる

プラットフォーム別の技術的考慮事項:

• WordPress / WooCommerce: wp_usermeta に ecauth_subject を保存、WordPress REST API またはadmin-ajaxでEcAuth API連携
• Magento: admin_user / customer_entity テーブルにサブジェクト紐付け、Magentoモジュールとして実装
• Shopify: Multipass API（Shopify Plus限定）またはCustomer Account API / Headless（Hydrogen）での連携に限定

展開優先順位:

1. EC-CUBE（コアターゲット、Phase 1〜4で全機能対応）
2. WordPress / WooCommerce（市場シェア、全機能対応可能）
3. Magento（EC特化、全機能対応可能）
4. Shopify（SaaS制約、B2Cの一部のみ）

6.2 今後の検討事項

• ベータテスト・パイロット導入計画
• サポート体制（ドキュメント、問い合わせ対応）
• 属性情報の変換・統合ルール
• 管理画面の実装
• 監視・ログ収集基盤
• 課金システムの構築（B2Bパスキー6ユーザー以上、B2C MAU課金）
• B2Bユーザー数カウント機能（Organization単位でのB2BUserカウント）
• マルチプラットフォーム展開に向けたプラグインSDK / 連携ガイドラインの策定
• 各プラットフォーム向けプラグインの開発・メンテナンス体制

7. 制約事項

• 新規サービスのため既存システムとの統合は不要
• セッション管理・シングルログアウトは現段階では実装しない
• Phase 1〜4はEC-CUBE側の要件に準拠した設計
• マルチプラットフォーム展開（Phase 5）はPhase 1〜4の完了後に着手
• SaaSプラットフォーム（Shopify等）は各社のAPI制約により提供可能な機能が限定される

8. 用語定義

• EcAuth: 本プロジェクトで開発する認証サービス
• IdP: Identity Provider（認証プロバイダー）
• MAU: Monthly Active Users（月間アクティブユーザー数）
• PKCE: Proof Key for Code Exchange
• WebAuthn: Web Authentication API（パスキー実装の標準）
• FIDO2: Fast IDentity Online 2（パスキー標準規格）
• B2B: Business-to-Business（管理者向け認証）
• B2C: Business-to-Consumer（エンドユーザー向け認証）
• RP ID: Relying Party Identifier（WebAuthnにおけるドメイン識別子）