認証（Authentication）入門

認証（Authentication）：「あなたは誰ですか？」
  → ユーザーの身元を確認する
  → ログイン処理がこれにあたる

認可（Authorization）：「あなたは何をしていいですか？」
  → 認証済みユーザーに権限を与える
  → 管理者だけが見られるページなどがこれにあたる

【セッション方式】
  サーバー側にセッション情報を保存（ステートフル）
  → サーバーが増えると全サーバーでセッション共有が必要
  → DBやRedisで一元管理が必要

【トークン方式（JWT）】
  サーバー側に保存しない（ステートレス）
  → どのサーバーでも署名を検証するだけでいい
  → サーバーレスアーキテクチャと相性が良い

✅ ブラウザが自動で毎回送ってくれる
✅ HttpOnly属性でJSから読めない → XSS攻撃に強い
✅ SameSite属性でCSRF対策ができる
✅ SSR対応
❌ 別ドメインには送れない（CORS制約）

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiIxMjMifQ.signature
      ↑                      ↑                    ↑
   Header               Payload              署名
（アルゴリズム情報）   （ユーザー情報など）  （改ざん検知）

@supabase/ssr パッケージが
JWTをHttpOnly Cookieで管理し
サーバーサイドでも認証状態を読めるようにしてくれる

【OAuthなしの場合】
  サービスAにGoogleのメールを見せたい
  → サービスAにGoogleのパスワードを教えるしかない → 危険

【OAuthありの場合】
  → Googleが「サービスAにメールだけ見せる許可証」を発行
  → サービスAはパスワードを知らなくていい

① ユーザーが「Googleでログイン」をクリック
② アプリ → Googleの認証画面にリダイレクト
③ ユーザーがGoogleにログイン・許可を承認
④ Google → アプリに「認可コード」を返す
⑤ アプリ → Googleに認可コードを送り「アクセストークン」と交換
⑥ アプリ → アクセストークンでGoogleからユーザー情報を取得
⑦ アプリ独自のJWTを発行してログイン完了

OAuth 2.0：「認可」のプロトコル
  → 「〇〇してもいいですよ」の許可証
  → リソースへのアクセス権限を委譲する

OIDC（OpenID Connect）：「認証」のプロトコル
  → OAuthの上に「認証」を追加した仕組み
  → 「この人は〇〇さんですよ」の身分証明
  → 「Googleでログイン」はOIDCを使っている

✅ オープンソース・無料
✅ データを自社サーバーで管理できる（金融・医療系）
✅ 社内複数サービスのSSO基盤として使える
❌ 自前でホスティング・運用が必要
❌ 個人開発には完全にオーバースペック

① XSS（Cross-Site Scripting）
  攻撃：悪意あるJSを埋め込みlocalStorageのJWTを盗む
  対策：
    ✅ JWTはHttpOnly Cookieに保存
    ✅ ユーザー入力を必ずエスケープ
    ✅ Content-Security-Policy（CSP）ヘッダーを設定

② CSRF（Cross-Site Request Forgery）
  攻撃：罠サイトから勝手にリクエストを送らせる
  対策：
    ✅ SameSite=Strict or Lax をCookieに設定
    ✅ CSRFトークンをリクエストに含める

③ ブルートフォース攻撃
  攻撃：パスワードを総当たりで試す
  対策：
    ✅ ログイン試行回数を制限（レートリミット）
    ✅ MFA（多要素認証）を導入
    ✅ Captchaを設置

④ トークン漏洩
  攻撃：JWTが盗まれると有効期限まで使い放題
  対策：
    ✅ JWTの有効期限を短くする（15分〜1時間）
    ✅ リフレッシュトークンで再発行する仕組みを使う
    ✅ HTTPS通信を強制する

アクセストークン（短命：15分〜1時間）
  → APIリクエストに使う
  → 漏洩しても短時間で無効

リフレッシュトークン（長命：数日〜数週間）
  → アクセストークンの再発行だけに使う
  → HttpOnly Cookieで厳重管理

流れ：
  ① アクセストークンの期限切れ
  ② リフレッシュトークンをサーバーに送る
  ③ 新しいアクセストークンを発行
  ④ ユーザーは再ログイン不要 ✅

❌ そのままDBに保存
❌ 単純な暗号化（復号できてしまう）
✅ bcryptでハッシュ化して保存

【登録時】
  パスワード "password123"
      ↓ bcryptでハッシュ化（サーバー側で実行）
  "$2b$10$xyz..." をDBに保存

【ログイン時】
  入力されたパスワードを同じようにハッシュ化
      ↓ DBの値と比較
  一致 → ログイン成功 ✅

// 登録時
const passwordHash = await bcrypt.hash('password123', 10);

// ログイン時
const isValid = await bcrypt.compare('password123', passwordHash);

SHA256などの単純なハッシュ → 高速・レインボーテーブルに弱い
bcrypt → 意図的に計算を遅くする・ソルトを自動付加
         → 同じパスワードでも毎回違うハッシュ値
         → 総当たり攻撃に強い ✅

// UIコンポーネントが付属 → ログイン画面をゼロで実装できる
import { SignIn } from '@clerk/nextjs';
export default function LoginPage() {
  return <SignIn />; // これだけでログイン画面が完成
}

// auth.ts
import { betterAuth } from 'better-auth';
import { drizzleAdapter } from 'better-auth/adapters/drizzle';

export const auth = betterAuth({
  database: drizzleAdapter(db, { provider: 'pg' }),
  socialProviders: {
    google: {
      clientId: process.env.GOOGLE_CLIENT_ID!,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
    },
  },
});

// Honoとの連携
app.on(['GET', 'POST'], '/api/auth/*', (c) => {
  return auth.handler(c.req.raw);
});

# 認証が必要なViewにデコレータをつけるだけ
from django.contrib.auth.decorators import login_required

@login_required
def my_page(request):
    return render(request, 'mypage.html')

✅ パスワードのハッシュ化（pbkdf2）
✅ セッション管理
✅ CSRFトークン
✅ @login_required デコレータ
✅ 管理画面の認証

// JWTの発行（ログイン時）
app.post('/auth/login', async (c) => {
  const { email, password } = await c.req.json();
  const user = await db.select().from(users)
    .where(eq(users.email, email)).limit(1);

  const isValid = await bcrypt.compare(password, user[0].passwordHash);
  if (!isValid) return c.json({ error: 'Unauthorized' }, 401);

  const token = await sign(
    { userId: user[0].id, exp: Math.floor(Date.now() / 1000) + 60 * 60 },
    process.env.JWT_SECRET!
  );

  setCookie(c, 'token', token, {
    httpOnly: true,
    sameSite: 'Strict',
    secure: true,
  });

  return c.json({ success: true });
});

// JWTの検証（ミドルウェア）
const authMiddleware = async (c, next) => {
  const token = getCookie(c, 'token');
  if (!token) return c.json({ error: 'Unauthorized' }, 401);

  try {
    const payload = await verify(token, process.env.JWT_SECRET!);
    c.set('userId', payload.userId);
    await next();
  } catch {
    return c.json({ error: 'Invalid token' }, 401);
  }
};

app.use('/api/*', authMiddleware);

スタート：認証を実装したい
    ↓
Q1. 自分のDBでユーザーを完全管理したいか？
    ├── No  → Q2へ
    └── Yes → Q5へ
    ↓
Q2. SupabaseをDBとして使っているか？
    ├── Yes → 【Supabase Auth】
    └── No  → Q3へ
    ↓
Q3. Next.js単体でSaaSを作っているか？
    ├── Yes → 【Clerk】
    └── No  → Q4へ
    ↓
Q4. AWSに統一したいか？企業向けSSO/SAMLが必要か？
    ├── Yes → 【AWS Cognito】
    └── No  → 【Auth0】
    ↓
Q5. Next.js + Honoの両方で認証を統一したいか？
    ├── Yes → 【Better Auth】
    └── No  → Q6へ
    ↓
Q6. Pythonが必要か？Djangoを使っているか？
    ├── Yes → 【Django標準認証 + simplejwt】
    └── No  → 【Hono自前JWT実装】

🥇 第一候補：Supabase Auth
  → DBと一体・RLSがそのまま使える
  → 追加コストなし・実装が最速

🥈 第二候補：Better Auth
  → ユーザーデータを自前DB（Drizzle）で管理したい場合
  → HonoとNext.jsの両方に対応

🥉 第三候補：Hono自前JWT
  → 認証の仕組みを深く学びたい場合
  → 特殊な認証フローが必要な場合

Supabase Auth
    ↓ ユーザーデータを自前管理したくなったら
Better Auth
    ↓ 完全にカスタマイズしたくなったら
Hono自前JWT実装