「アプリ」認証追加

Transcript

1. Supabase 認証基盤の導入 2025.11.25 マッチングアプリ開発 nikawa2161 1
2. 本日のアジェンダ 1. 認証基盤の選定 2. Supabase Auth の実装 3. 今後の課題と改善 nikawa2161 2
3. 認証基盤の選定 自前で構築したくない →SaaS 選定 候補: Auth0 Clerk Supabase Auth nikawa2161 3
4. ユースケース マッチングアプリの要件 SNS / メールアドレス / 電話番号でログイン アプリを繰り返し開く 個人利用が前提 シンプルなログイン体験が重要 企業向け SSO は不要 UI はシンプルで十分 nikawa2161 4
5. 認証基盤の比較 項目 Auth0 Clerk Supabase 想定利用者 企業・B2B SaaS / 個人向け 個人向け SSO 強い そこそこ 弱い UI 独自 UI 強い UI 優秀 最低限 開発体験 複雑 手軽 シンプル 価格 やや高い 中程度 最安 nikawa2161 5
6. Supabase Auth を選んだ理由 1. 要件とのマッチ SSO 不要 シンプルな個人向けアプリに最適 2. 統一管理 DB も Supabase を使う予定 auth.users とアプリ users が同じ DB 外部連携不要 3. コストと柔軟性 無料枠が広い 後から UI カスタマイズ可能 nikawa2161 6
7. Supabase 認証の仕組み 2 つのテーブルを連携 auth.users（Supabase 管理） 認証情報のみを保持 users（アプリ管理） プロフィール等のアプリ固有情報 なぜ分ける？ → 認証と業務データの責務分離 nikawa2161 7
8. ユーザーテーブル設計 CREATE TABLE users ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), supabase_auth_id UUID UNIQUE NOT NULL, created_at TIMESTAMP DEFAULT NOW(), updated_at TIMESTAMP DEFAULT NOW() ); ポイント: supabase_auth_id で認証ユーザーと紐付け UNIQUE 制約で 1 対 1 を保証 nikawa2161 8
9. 連携の仕組み トリガー + ファンクションで自動連携 1. ユーザーが新規登録 2. auth.users にレコード作成 3. トリガーが発火 4. ファンクションが実行 5. users テーブルにレコード作成 メリット: 自動同期・アプリ側で意識不要 nikawa2161 9
10. 実装の流れ ユーザー新規登録 ↓ auth.users 作成 ← Supabase管理 ↓ トリガー発火 ↓ ファンクション実行 ↓ nikawa2161 10
11. トリガー実装 CREATE TRIGGER on_auth_user_created AFTER INSERT ON auth.users FOR EACH ROW EXECUTE FUNCTION handle_new_user(); 役割: auth.users への INSERT を検知 handle_new_user() 関数を呼び出す nikawa2161 11
12. ファンクション実装 CREATE FUNCTION handle_new_user() RETURNS TRIGGER AS $$ BEGIN INSERT INTO public.users (supabase_auth_id) VALUES (NEW.id); RETURN NEW; END; $$ LANGUAGE plpgsql SECURITY DEFINER; 役割: supabase_auth_id に認証 ID を設定 users テーブルに新規レコード作成 nikawa2161 12
13. 認証パッケージ化 packages/auth/src/ ├── client/ # ブラウザ実行コード │ ├── hooks/ # Reactフック │ └── supabase.ts # クライアント ├── server/ # サーバー実行コード │ ├── actions/ # Server Actions │ ├── supabase.ts # サーバークライアント │ └── utils.ts # ユーティリティ └── types/ # 型定義 方針: クライアント側で処理する方向で実装 nikawa2161 13
14. 現状の課題 ロールバック機構がない users テーブル作成に失敗した場合 auth.users はそのまま残る データの不整合が発生する可能性 nikawa2161 14
15. 今後の改善案 1. エラーハンドリング強化 ファンクション内でエラーをキャッチ ロールバック対応 2. リトライ機構 失敗時に自動再試行の検討 3. 監視・アラート 不整合検知の仕組み nikawa2161 15
16. まとめ やったこと Supabase Auth を認証基盤に選定 auth.users と users の自動連携 認証処理をパッケージ化 現状の課題 ロールバック機構がない エラー時のデータ不整合リスク 今後の方針 まずは動くものを優先 課題は運用しながら改善 nikawa2161 16