「Webアプリの認証ってBasic・JWT・OAuthとあるけど、結局どれをいつ使えばいいの？」——そんな悩みに答えるため、本記事では Web認証方式の代表5種類（Basic / Digest / Cookie / トークン / OAuth）の違いを、シーケンス図と使い分け軸で一気に整理します。
結論を先に言うと、2026年現在の主流は「ブラウザアプリならCookieセッション、SPA/モバイルならJWT、外部ログイン連携ならOAuth 2.0 + OIDC」です。Basic/Digest はレガシーで本番ではほぼ使いません。なぜそうなるのか、仕組みとセキュリティ特性を比較表＋シーケンス図で順に見ていきます。
先に結論｜Web認証方式5種類の比較表
各方式の解説に入る前に、5つの認証方式を1枚の表で見比べておきましょう。本文を読んだあと、ここに戻って判断材料にするのがオススメです。
| 方式 | 送るもの | 状態管理 | 主なリスク | 2026年現在の用途 |
|---|---|---|---|---|
| Basic | ID:PASS（Base64） | 都度送信 | 盗聴されると即漏洩 | 社内ツール／API一時保護のみ |
| Digest | MD5ハッシュ | 都度送信 | MD5脆弱・実装が複雑 | レガシー保守のみ（新規採用×） |
| Cookie（セッション） | セッションID | サーバー保持 | CSRF・セッションハイジャック | 従来型ブラウザWebアプリの主流 |
| JWT（トークン） | 署名付きJWT | ステートレス | XSSでの盗難・失効困難 | SPA／モバイル／マイクロサービス |
| OAuth 2.0 / OIDC | アクセストークン | 外部IdPに委任 | 同意画面の偽装・スコープ過大 | 「Googleでログイン」など外部連携 |
Basic認証
Digest認証
Basic認証を改良した方式で、パスワードをそのまま送らずにハッシュ値を送信します。
これにより、盗聴されても平文パスワードが直接漏れない仕組みになっています。
Cookie認証
ログインに成功すると、サーバーは「セッションID」を発行し、Set-Cookie ヘッダでブラウザに渡します。
ブラウザは以降のリクエストで、そのCookieを自動的に送信することで認証を維持します。
実際にCookie認証でやり取りされるHTTPの中身を見ておくとイメージが固まります。curl -v でログインAPIを叩いた抜粋です。
# ログインリクエスト
> POST /api/login HTTP/2
> Content-Type: application/json
>
> {"email":"taro@example.com","password":"****"}
# サーバーのレスポンス（Cookieが発行される）
< HTTP/2 200
< Set-Cookie: session_id=8f9b2a4c1e7d3f6a; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=3600
# 以降のリクエスト（ブラウザは自動でCookieを送信）
> GET /api/me HTTP/2
> Cookie: session_id=8f9b2a4c1e7d3f6aHttpOnly; Secure; SameSite=Lax の3点セットがそろっていれば、JavaScriptからの読み出し（XSS対策）・HTTP通信の遮断（盗聴対策）・クロスサイトでの自動送信抑止（CSRF対策）の主要3攻撃を防げます。僕は過去のプロジェクトで HttpOnly 抜けのCookieを納品直前に発見してリリース延期になった経験があるので、レビューでは必ずこの3属性をチェックしてください。
トークン認証（例: JWT）
ログインするとサーバーが「トークン（署名付きの身分証明書）」を発行し、
以後のリクエストではそのトークンを使って認証を行います。
JWTがどんな見た目なのか、実物を見せておきます。xxx.yyy.zzz の3パートで構成され、それぞれBase64URLでエンコードされた JSON です。
// 実際のJWT（改行は便宜上）
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJUYW5ha2EiLCJleHAiOjE3MzU2ODk2MDB9.
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
// デコード結果
ヘッダー: {"alg":"HS256","typ":"JWT"}
ペイロード: {"sub":"user_123","name":"Tanaka","exp":1735689600}
署名: HMAC-SHA256(base64(header) + "." + base64(payload), secret)注意したいのは、ヘッダーとペイロードは「暗号化」ではなく単なる「Base64エンコード」なこと。誰でもデコードして中身が読めるので、JWTにパスワードや個人情報を入れてはいけません。署名（zzz）が改ざん検知の役割を担っており、署名検証なしでJWTを信用するのが最もよくある脆弱性パターンです。
OAuth（例: 「Googleでログイン」）
自分のパスワードをアプリに渡さずに、他のサービス（GoogleやAppleなど）に「認証・認可」を任せる仕組みです。
OAuthとOIDCの違い｜混同しがちな2つを整理
「Googleでログイン」と聞くと OAuth 2.0 を思い浮かべますが、厳密には OAuth 2.0 は 「認可」の仕組みで、ユーザーの本人確認（認証）を保証するものではありません。本人確認まで含めて行いたいときに使うのが、OAuth 2.0 を土台に拡張された OIDC（OpenID Connect）です。
- OAuth 2.0: 「このアプリにあなたのデータへのアクセスを認可しますか？」（＝認可）
- OIDC: OAuth 2.0 + IDトークン（JWT形式）で「あなたが誰か」を証明（＝認証）
2026年現在、Google・Microsoft・Apple・LINE などの「○○でログイン」はすべて OIDC で実装されています。「OAuthでログイン」と言うときの実体はOIDCである、と覚えておくと混乱しません。
まとめ
- Basic認証: IDとパスワードを直接送る（古い、要HTTPS）
- Digest認証: ハッシュを使う（今はほぼ使わない）
- Cookie認証: クッキーに印をつけて確認する
- トークン認証（JWTなど）: 合言葉を発行して、それを持ち歩く
- OAuth: 他のサービスに本人確認を頼む
実務での選び方｜2分でできる判断フロー
「どれを選べばいいのか分からない」を一掃するため、僕が新規設計時に実際に使っている5ステップの判断フローを共有します。
- 外部サービス（Google/Apple等）でログインさせたい？ → Yesなら OAuth 2.0 + OIDC。ここで完結
- SPA／モバイルアプリ／マイクロサービス間の通信？ → Yesなら JWT（短命アクセストークン＋リフレッシュトークン）。HttpOnly Cookieに格納
- サーバーサイドレンダリング型のブラウザWebアプリ？ → Yesなら Cookieセッション。HttpOnly + Secure + SameSite=Lax で発行
- 社内ツール・ステージング・暫定保護のみ？ → 上記が過剰なら Basic + HTTPS でも可。ただし本番ユーザー向け禁止
- 新規実装で多要素・パスワードレスを目指す？ → 1〜3に パスキー（WebAuthn）を組み合わせる（2026年現在の最新ベストプラクティス）
このフローで決めれば「とりあえずJWTにしたら失効が効かなくて困った」「セッションのまま増え続けてRedisが破綻した」といった典型的な失敗を回避できます。
FAQ｜Web認証方式によくある質問
Q. JWTとセッション（Cookie）はどちらを選ぶべき？
同一ドメインのブラウザWebアプリならCookieセッションが安全かつシンプルでオススメです。複数のサブドメイン・モバイルアプリ・SPA・マイクロサービス間でトークンを使い回すならJWT（OAuth/OIDCのアクセストークン）が向いています。「失効を即座に効かせたい」要件があるならJWTより短命トークン＋リフレッシュトークンを併用してください。
Q. JWTをLocalStorageに保存するのは危険？
XSSが発生したときにJSから読み出されるリスクがあるため、近年は HttpOnly + Secure + SameSite=Lax（または Strict）を付けたCookieに格納する方が安全とされています。OWASPもJWTのLocalStorage保存を非推奨にしています。
Q. Basic認証を今でも使ってよい場面は？
HTTPS必須かつ暫定的な保護なら許容範囲です。具体的には、社内ツールの暫定アクセス制限、ステージング環境のクローラー除けなど。本番のユーザー向け認証としては、CSRF/総当たり/フィッシング耐性のいずれも弱いため避けるのが2026年現在の定石です。
Q. パスキー（WebAuthn/FIDO2）はどの分類？
パスキーは「公開鍵暗号で本人確認する第6の認証方式」と位置付けられ、2024年以降Apple/Google/Microsoftが本格採用したことで2026年現在は急速に普及しています。本記事の5方式とは別レイヤーの「ファクタ」で、Cookieセッション や OIDC と組み合わせて利用します（例: パスキーでログイン → セッションCookie発行）。
