セクション 34 / 42
Web開発
ログイン機能（認証）
会員機能の心臓部。自分で作らず“専門サービス”に任せる
会員登録・ログイン・マイページ——多くのアプリに欠かせないのが認証（にんしょう）です。認証とは「この人は本当に本人か？」を確かめる仕組みのこと。
認証と認可（似てるけど別物）
- 認証（Authentication）
- あなたは誰？を確かめる（＝ログイン）。
- 認可（Authorization）
- あなたは何をしてよい？を決める（例：自分のデータだけ見られる）。
鉄則：認証を“ゼロから自作”しない
パスワードの安全な保存、総当たり攻撃への対策、再設定メール……認証には専門的な落とし穴が山ほどあります。そこで、認証つきのサービス（BaaS）に任せるのが現代の定番です。
- Supabase
- 認証＋データベースのセット。このサイトの会員機能もこれ。
- Firebase
- Googleの定番。スマホアプリにも強い。
- Clerk / Auth0
- 認証専門。きれいなログイン画面を手早く用意できる。
このサイトのログインもSupabase製
あなたが使った会員登録・ログイン・進捗保存は、まさにSupabaseで動いています。「Supabaseで会員機能を付けて」と頼めば、Claude Codeが同じような仕組みを組んでくれます。
落とし穴：RLS（行レベルセキュリティ）の設定漏れ
SupabaseなどのBaaSでは、RLSという「自分の行しか触れない」設定がデータの門番です。アプリの画面で隠しても関係なく、RLSが抜けたテーブルは世界中の誰でも全データを読めてしまいます（実際に頻発している事故です）。AIに作らせたら「全テーブルでRLSが有効か、ポリシーは“自分の行のみ”になっているか確認して」と必ず頼みましょう。
知っておくと安心の言葉
- ハッシュ化：パスワードを“元に戻せない形”に変換して保存すること。そのまま（平文）保存は重大事故。
- ソーシャルログイン：「Googleでログイン」のように他サービスのアカウントを借りる方式。
- 二段階認証（2FA）：パスワード＋確認コードで二重に守る仕組み。
パスワードを自分で抱えない
認証サービスに任せれば、パスワードの保存や保護はサービス側が引き受けてくれます。「自分のデータベースに生のパスワードを保存」だけは絶対にしないこと。
頼み方の例
「Supabaseでメール＋パスワードのログインを付けて。ログインした人だけマイページを見られるように」——認証（ログイン）と認可（誰が何を見られるか）をセットで伝えるのがコツです。
理解度チェック
読み込み中…