認証と認可の実装

セキュリティで、認証と認可の違いを扱いました。

認証（Authentication）  あなたが誰か     → ログイン
認可（Authorization）   何をしてよいか   → 権限チェック

この章では、それを実際にどう実装するかを扱います。 自分でゼロから作ることは（後述するように）ほとんどありませんが、 仕組みを知らないまま使うと、必ず穴を空けます。

大前提: 自分で作らない

暗号やプロトコルの実装を自作するのは、ほぼ確実に間違いです。

それでも仕組みを学ぶのは、「使い方を間違えないため」です。 この章の目的は、実装できるようになることではなく、 レビューで穴に気づけるようになることです。

パスワードの扱い

保存

平文で保存               論外
MD5 / SHA-1 / SHA-256    不十分（GPU で秒間数十億回試せる）
bcrypt / argon2 / scrypt  正解（意図的に遅く、計算資源を要求する）

// bcrypt: ソルトは自動で生成され、ハッシュ文字列に含まれる
hash, err := bcrypt.GenerateFromPassword([]byte(password), bcrypt.DefaultCost)
 
// 照合
err = bcrypt.CompareHashAndPassword(storedHash, []byte(inputPassword))

ソルトとペッパー

ソルトは、ユーザーごとに違うランダム値です。 これが無いと、同じパスワードの人が同じハッシュになり、 事前計算した表（レインボーテーブル）で一気に破られます。

bcrypt / argon2 はソルトを自動で生成し、結果の文字列に含めます。 自分でソルトを管理する必要はありません。

照合時の注意

// 悪い: ユーザーの存在有無が漏れる
user, err := store.FindByEmail(email)
if err != nil { return errors.New("そのメールアドレスは登録されていません") }
if !checkPassword(user, password) { return errors.New("パスワードが違います") }
 
// 良い: どちらでも同じメッセージ・同程度の処理時間にする
if err != nil || !checkPassword(user, password) {
    return errors.New("メールアドレスまたはパスワードが正しくありません")
}

エラーメッセージを分けると、そのメールアドレスが登録済みかを外部から判定できます （アカウント列挙）。パスワードリセット画面でも同じ配慮が必要です。

ログイン状態をどう保つか

Web と HTTPで見たとおり、HTTP はステートレスです。 ログイン後の各リクエストで「自分が誰か」を示す必要があります。

方式は大きく2つです。

セッション方式

1. ログイン成功 → ランダムなセッション ID を発行
2. サーバー側に「このID = ユーザー123」を保存（Redis など）
3. Cookie でクライアントに渡す
4. 以降のリクエストで Cookie が自動的に送られる
5. サーバーはストアを引いてユーザーを特定する

まずこれを検討してください。 単純で、失効させられます。

Cookie の属性は必ず設定する

http.SetCookie(w, &http.Cookie{
    Name:     "session",
    Value:    sessionID,
    HttpOnly: true,                    // JavaScript から読めない（XSS で盗まれない）
    Secure:   true,                    // HTTPS でのみ送信される
    SameSite: http.SameSiteLaxMode,    // 他サイトからの遷移では送らない（CSRF 対策）
    Path:     "/",
    MaxAge:   60 * 60 * 24 * 7,
})

この3つは必ず設定します。 レビューで真っ先に見るポイントです。

ペイロード  実際に運びたいデータ本体（ヘッダなどの付随情報を除いた部分）
クレーム    JWT の中に入っている個々の項目（sub / exp / iss など）

トークン方式（JWT）

JWT は、署名付きの JSON です。ピリオドで区切られた3つの部分からできています。

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMiLCJleHAiOjE3NTQ2MDAwMDB9.dBjftJeZ4CV...
└──── header ────┘ └────────── payload ──────────┘ └── signature ──┘
   署名アルゴリズム      中身（ユーザーID、有効期限）      改ざん検知用の署名

echo 'eyJzdWIiOiIxMjMifQ' | base64 -d    # {"sub":"123"}

トークンをどこに保存するか

localStorage         → XSS があれば JavaScript で読み取られる
HttpOnly Cookie      → JavaScript から読めない。CSRF 対策とセットで使う
メモリ（変数）        → タブを閉じると消えるが、最も漏れにくい

「localStorage に JWT」は広く見かけますが、XSS 一発で終わります。 可能なら HttpOnly Cookie を選んでください。

OAuth 2.0 — パスワードを渡さずに権限を委譲する

「このアプリに Google カレンダーを読ませたい」時、 Google のパスワードをそのアプリに渡すわけにはいきません。

OAuth 2.0 は、この問題を解決する仕組みです。

登場人物
  リソースオーナー   あなた（ユーザー）
  クライアント       権限が欲しいアプリ
  認可サーバー       Google（同意を取り、トークンを発行する）
  リソースサーバー   Google カレンダー API

認可コードフロー（+ PKCE）

現在の標準的なフローです。

1. アプリが、ブラウザを認可サーバーへ送る
   （+ code_challenge = ランダム値のハッシュ を添える）
2. ユーザーが Google でログインし、「カレンダーの閲覧を許可」に同意
3. 認可サーバーが、アプリのリダイレクト URI に「認可コード」を返す
4. アプリがサーバー側で、認可コード + code_verifier（元のランダム値）を送る
5. 認可サーバーがアクセストークンを返す
6. アプリがそのトークンでカレンダー API を呼ぶ

要点は2つです。

• ステップ3の認可コードは、それだけでは使えない（4 で交換が必要）
• PKCE により、認可コードを横取りされても code_verifier を知らない攻撃者はトークンに交換できない

OIDC — OAuth は認証ではない

OAuth 2.0 は「認可」の仕組みで、「この人が誰か」は保証しません。

「Google でログイン」を実現するには、その上に載る OpenID Connect（OIDC） を使います。

OAuth 2.0      → アクセストークン（何ができるか）
OIDC を足す    → ID トークン（誰であるか。JWT 形式）

ID トークンには sub（そのユーザーの一意な ID）、 email、iss、aud、exp が入っています。

アクセストークンを認証に使ってはいけません。 「トークンが有効だから本人」という判断は、 別のアプリ向けに発行されたトークンを持ち込まれると破綻します。 aud を検証できる ID トークンを使ってください。

認可 — 実装ミスが最も多い場所

認証より、認可のほうがはるかに事故ります。 認証は「通るか通らないか」なので気づきますが、 認可の漏れは正常に動いているように見えます。

モデル

実務では RBAC + リソースベースの組み合わせが最も多いです。

最頻出の脆弱性: IDOR

// 危険: ログインしていれば、他人の注文も見られる
func GetOrder(ctx context.Context, id string) (*Order, error) {
    return store.FindOrder(ctx, id)
}

ログインはしているので認証は通っています。 しかし「その注文が自分のものか」を確認していません。

URL の /orders/1001 を /orders/1002 に書き換えるだけで、 他人の注文が見えます。これを IDOR（安全でない直接オブジェクト参照）と呼びます。

// 正しい: 所有者を条件に含める
func GetOrder(ctx context.Context, userID, orderID string) (*Order, error) {
    o, err := store.FindOrder(ctx, orderID)
    if err != nil { return nil, err }
    if o.UserID != userID {
        return nil, ErrNotFound   // ← ErrForbidden ではなく NotFound を返す
    }
    return o, nil
}

サービス間の認証

マイクロサービスの実務のマイクロサービスでは、サービス同士も認証します。

実務の落とし穴まとめ

1. パスワードを SHA-256 で保存 — bcrypt / argon2 を使う
2. ログイン失敗のメッセージを分ける — アカウントの存在が漏れる
3. Cookie に HttpOnly / Secure / SameSite が無い — 盗まれる
4. JWT に個人情報を入れる — 暗号化されていない。誰でも読める
5. JWT で即時ログアウトを実装しようとする — 原理的にできない
6. alg を固定せず検証 — 署名検証が素通りする
7. localStorage にトークン — XSS で盗まれる
8. OAuth の state を検証しない — CSRF が成立する
9. リダイレクト URI を前方一致で検証 — 攻撃者に送れてしまう
10. アクセストークンで本人確認 — 認証には ID トークンを使う
11. 所有者チェックの漏れ（IDOR） — 最も多い実害
12. 画面でボタンを隠して認可したつもり — API は直接叩ける

まとめ

• 暗号・プロトコルは自作しない。仕組みを学ぶのは穴に気づくため
• パスワードは bcrypt / argon2。そもそも持たない選択肢を先に検討する
• ログイン状態は、まずセッション方式を検討する。 Cookie には HttpOnly Secure SameSite を必ず付ける
• JWT は暗号化されておらず、失効もできない。 短命のアクセストークン + 失効可能なリフレッシュトークンで運用する
• OAuth 2.0 は認可、OIDC が認証。認可コードフロー + PKCE を使う
• 認可のほうが事故る。所有者チェック（IDOR）を必ず入れ、 既定で拒否し、サーバー側で、全エンドポイントに適用する
• 存在を隠したいものは 404 を返す

公式ドキュメント

迷ったら一次情報に戻ってください。

章末問題

次の章では、ここまでの防御が構造的に効かない領域を扱います。 LLM には、命令とデータを分離する手段がありません。