認証と認可

ログインしたユーザーを、次のリクエストでどう見分けるかの方法には、大きく2つあります。

• セッション：サーバーが「このセッション ID はユーザー 42」と保存し、ブラウザには ID だけを Cookie で渡す。
• JWT（JSON Web Token）：ユーザー ID や期限をトークンの中に入れて署名する。サーバーは署名を確かめるだけで、保存先を引かなくてよい。中身は Base64 で、暗号化はされていない（誰でも読める）。

• 保存場所：localStorage に置くと、XSS があれば JS から盗まれる。ブラウザなら HttpOnly; Secure; SameSite の Cookie に入れるほうが盗まれにくい（その場合は CSRF 対策も要る）。
• 失効：アクセストークンの期限は短く（5〜15分程度）し、長く使うリフレッシュトークンはサーバーで管理して失効できるようにする。リフレッシュトークンは使うたびに新しくする（ローテーション）と、盗まれたことに気づきやすい。
• 検証：署名のアルゴリズムを固定する（alg: none や想定外のアルゴリズムを受け付けない）、exp（期限）・iss（発行者）・aud（宛先）を確かめる。実績のあるライブラリを使う。
• 中身は誰でも読めるので、個人情報や秘密を入れない。

同じドメインの普通の Web アプリなら、まずはセッションで十分なことが多いです。「JWT ならスケールする」だけを理由に選ぶと、失効の難しさを後から抱えます。

OAuth 2.0 は、ユーザーのパスワードを渡さずに、別のアプリに「この範囲の操作だけしてよい」という許可（アクセストークン）を与える仕組みです（認可）。OIDC（OpenID Connect）は OAuth の上に「この人は誰か」を伝える仕組みを足したもので、「Google でログイン」のような認証に使います。

認可コードフロー＋PKCE

今の Web・スマホのアプリでは、このフローが標準です。

• アプリが、ランダムな code_verifier を作り、そのハッシュ（code_challenge）と、ランダムな state を用意する。
• ユーザーを認可サーバー（Google など）へリダイレクトする：/authorize?response_type=code&client_id=…&redirect_uri=…&scope=openid email&state=…&code_challenge=…&code_challenge_method=S256
• ユーザーがログインして許可すると、redirect_uri?code=…&state=… に戻ってくる。
• アプリは state が自分の送ったものと同じか確かめる（違えば CSRF の可能性があるので止める）。
• アプリのサーバーが code と code_verifier をトークンエンドポイントに送り、アクセストークン（と ID トークン・リフレッシュトークン）を受け取る。

OAuth のセキュリティの指針（RFC 9700）では、PKCE は公開クライアント（SPA・スマホアプリなど秘密を持てないもの）では必須、サーバーで秘密を持てるアプリでも推奨とされています。トークンを URL で直接返す「インプリシットフロー」は使わないよう勧められています。

• ID トークン（OIDC）：「誰がログインしたか」をアプリに伝える JWT。sub（ユーザーの一意の ID）・iss・aud（自分のクライアント ID か）・exp・nonce を確かめてから使う。ユーザーを結びつけるのはメールアドレスではなく iss と sub の組で。
• アクセストークン：API を呼ぶための許可証。scope で範囲が決まる。宛先の API が確かめるもので、ログインの証明に使ってはいけない。

パスワードの保存方法

パスワードは、元に戻せないパスワード専用のハッシュ関数で保存します。漏れても元のパスワードが分かりにくいようにするためです。

• 使う：Argon2id・bcrypt・scrypt。わざと遅く作られていて、総当たりに時間がかかる。ユーザーごとのランダムな値（ソルト）も自動で入る。
• 使わない：平文、暗号化（鍵があれば戻せる）、MD5・SHA-256 をそのまま（速すぎて総当たりされる）。
• ハッシュの強さ（コスト）は、サーバーで1回 数十〜数百ms になる程度に調整する。
• ログインには回数制限を付け、「メールアドレスが違います」と「パスワードが違います」を分けずに伝える。漏えいしたパスワードの一覧と照合して弱いものを断るのも有効。

多要素認証は、パスワード（知っているもの）に、別の種類の要素（持っているもの・本人の体）を足す仕組みです。

パスワードに加えて、別の要素（持っているもの・本人の体）を求めます。

MFA を入れたら、端末をなくしたときの回復の手段（回復コード・別の要素の登録）が攻撃の抜け道にならないよう、同じくらい慎重に作ります。

パスキーは、端末の中で作った公開鍵と秘密鍵の組でログインする仕組みです。サーバーには公開鍵だけを保存し、ログインのたびに端末が秘密鍵で署名します。秘密鍵は端末から出ず、指紋や顔・PIN で使います。

• サーバーに漏れて困るパスワードがない。
• 鍵はサイトのドメインに結びつくので、偽サイトでは使えず、フィッシングに強い。
• 実装はブラウザの navigator.credentials.create()／get() と、サーバー側の検証ライブラリ（SimpleWebAuthn など）を使う。端末をなくしたときの復旧手段（別のパスキー・回復手段）を用意しておく。

認証は「誰か」を確かめること、認可は「その人がそれをしてよいか」を決めることです。認可の漏れは OWASP Top 10 でも一番上にある、よく起きる問題です。

RBAC・ABAC

多くのアプリは RBAC から始め、足りない所に「自分のデータか」などの条件を足します。判定の処理は1か所（ポリシーの関数・Pundit・CASL など）にまとめ、各 API に散らばらないようにします。

IDOR（安全でない直接オブジェクト参照）は、GET /orders/1001 の ID を 1002 に変えるだけで、他人の注文が見えてしまう問題です。ログインしているかしか確かめていないと起こります。

// 危ない
const order = await db.order.findUnique({ where: { id } });
// 安全：持ち主の条件を付ける
const order = await db.order.findFirst({ where: { id, userId: currentUser.id } });
if (!order) return res.status(404).end();

• すべての API で、データの持ち主か・権限があるかをサーバーで確かめる。画面でボタンを隠すだけでは守れない。
• マルチテナントでは、tenant_id の条件を必ず付ける仕組み（共通のスコープ・PostgreSQL の行レベルセキュリティ）にする。
• 推測しにくい ID（UUID）にするのは助けになるが、権限の確認の代わりにはならない。
• 「他のユーザーで見ると 404 になる」ことをテストに書く。