自社複数アプリの共通アカウント（SSO の最小構成）

背景与問題

OPC（B 方向）。アプリが複数育った時、ユーザーが各アプリで別アカウントを作る体験が重くなる。統合判断（opc-app-unification-decision）でアプリを分けたままにする場合、共通アカウント（SSO）が体験を繋ぐ代替手段になる。構成の型と導入タイミングを決める。

发现

（出典は 2026-09-17 アクセス。WebSearch 枠切れのため通説ベース——API の現行仕様は次回確認）

• プラットフォームネイティブ SSO の事実：同一 Team ID の iOS アプリは credential 共有が可能、同一署名鍵の Android アプリは Credential Manager で資格を共有できる（通説）——自社内 SSO は IdP を作らなくても成立し得る。
• 中央 IdP 型：Firebase Auth/Auth0/Keycloak 等を単一テナントにして全アプリから参照する構成（通説）。
• 共通の論点：token の保管・リダイレクト URI の整合・token 更新・単一ログアウト（logout propagation）・同意 UX（通説）。
• iOS の Keychain access group で同一チームのアプリ間 token 共有も可能（通説）。
• 推测：アプリ 2 本目までは「アカウントなし」（opc-icloud-sync-arch の iCloud 承り）で済み、3 本目から統一の価値が出る。

结论

1. 導入タイミングの引金：アプリ 3 本目の登場または「アプリ間で同じデータを使う」需要の観測。2 本目まではアカウントなし+iCloud 承り（推测ベースの設計判断）。
2. 導入するならプラットフォームネイティブ SSO を第一候補に：Team ID/署名鍵による credential 共有は中央 IdP 構築より安い（事実の整理）。IdP は規模が出てから。
3. 単一ログアウトを必須機能に：複数 app の token が散在したままログアウト漏れは事故源——logout propagation を含まない SSO は導入しない（通説の論点）。
4. 認証方式は passkey 一本化：共通アカウントの認証は opc-passkey-senior-login の設計（生体+回復経路）に統一し、パスワード路線を作らない。

待办 / 下次继续

• 現行アプリ間のユーザー重複の有無を確認（SSO の需要実値）。
  
• Keychain access group / Credential Manager の仕様を 1 回確認。
  

关联

opc-app-unification-decision opc-icloud-sync-arch opc-passkey-senior-login opc-old-version-support-policy