「Webアプリの認証、Basic・JWT・OAuthのどれを使えばいいのか結局わからない」。そういう人向けに、結論から言います。
2026年現在の主流は、ブラウザアプリならCookieセッション、SPA/モバイルならJWT、外部ログイン連携ならOAuth 2.0 + OIDCの3択です。
Basic/Digestはレガシーで、新規の本番実装ではまず選びません。
Web認証の代表5方式（Basic / Digest / Cookie / トークン(JWT) / OAuth）を仕組み・シーケンス図・セキュリティリスクの3軸で比較し、最後に「どれを選べばいいか」を2分で判断できるフローまで用意しています。
読み終える頃には、自分のプロジェクトにどの方式が向くか迷わず答えられるはずです。
Web認証とは｜認証と認可の違いも整理
Web認証（Authentication）とは、Webサイトやアプリにアクセスしてきた相手が「本人（あるいは正当なクライアント）かどうか」をサーバー側が確認する仕組みのことです。
ID・パスワードの照合、トークンの検証、外部サービスへの委任など、確認の方法は複数ありますが、目的は共通して「なりすましを防ぎ、正しい相手にだけアクセスを許可する」ことにあります。
ここで混同しやすいのが「認証（Authentication）」と「認可（Authorization）」の違いです。
認証は「あなたは誰か」を確認する処理、認可は「あなたに何を許可するか」を決める処理です。
例えばログインは認証、ログイン後に「この機能は管理者だけ使える」と制限するのは認可にあたります。
後述するOAuthは本来この「認可」の仕組みであり、認証と混同される代表例です。
なぜBasic・Digest・Cookie・JWT・OAuthという複数の方式が存在するのかといえば、想定するクライアント（ブラウザなのかモバイルアプリなのか外部サービスなのか）とセキュリティ要件がケースごとに異なるためです。
次の比較表で全体像をつかんでから、各方式の仕組みを見ていきましょう。
先に結論｜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認証
基本認証と先進認証（モダン認証）の違い
ここまで解説してきたBasic認証は「基本認証（Basic Authentication）」とも呼ばれます。
これに対して先進認証（モダン認証／Modern Authentication）という言葉を聞いたことがある人も多いはずです。
先進認証は、OAuth 2.0をベースにトークンでアクセスを制御し、多要素認証（MFA）にも対応できる認証方式の総称で、本記事のOAuth 2.0/OIDCがこれに相当します。
この対比が実務で意識されるようになった代表例が、Microsoft Exchange Onlineです。
2022年10月以降、ID・パスワードを都度送信する基本認証（Basic認証）は段階的に廃止され、先進認証（モダン認証）への移行が必須になりました。
「基本認証＝本記事のBasic認証」「先進認証＝本記事のOAuth 2.0/OIDC」と対応付けて覚えておくと、業務システムの移行案件でも迷いません。
この2語だけ覚えておけば十分です。
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.
eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJUYW5ha2EiLCJleHAiOjE3NjcyMjU2MDB9.
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
// デコード結果
ヘッダー: {"alg":"HS256","typ":"JWT"}
ペイロード: {"sub":"user_123","name":"Tanaka","exp":1767225600}
署名: HMAC-SHA256(base64(header) + "." + base64(payload), secret)※ exp は分かりやすさのための例です。実際は発行から数分〜数時間程度の短命な値を使います。
注意したいのは、ヘッダーとペイロードは「暗号化」ではなく単なる「Base64エンコード」なこと。
誰でもデコードして中身が読めるので、JWTにパスワードや個人情報を入れてはいけません。
署名（zzz）が改ざん検知の役割を担っており、署名検証なしでJWTを信用するのが最もよくある脆弱性パターンです。
加えて見落としやすいのが「alg=none脆弱性」です。
JWTのヘッダーで指定する署名アルゴリズム（alg）を検証側が信用してしまうと、攻撃者がalgをnoneに書き換えて署名チェックを丸ごとバイパスできます。
なお、これとは別に「アルゴリズム混同攻撃（RS256↔HS256）」という脆弱性もあります。
RSA公開鍵（RS256）をHMAC共有鍵（HS256）として誤って検証してしまう問題で、alg=noneとは異なる攻撃手法です。
いずれも「ヘッダーのalgを検証側が無条件に信用する」ことが根本原因のため、対策は共通してアルゴリズムの明示的な固定です（例: HS256のみ許可し、リクエストされたalgをそのまま信用しない）。
OAuth（例: 「Googleでログイン」）
自分のパスワードをアプリに渡さずに、他のサービス（GoogleやAppleなど）に「認証・認可」を任せる仕組みです。
Google以外にもApple・Microsoft・LINE・GitHubなど主要サービスの多くがOAuth 2.0/OIDCベースの外部ログインを提供しています。
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/FIDO2）を組み合わせる（2026年現在、主要サービスで移行期に入っているベストプラクティス）
このフローで決めれば「とりあえずJWTにしたら失効が効かなくて困った」「セッションのまま増え続けてRedisが破綻した」といった典型的な失敗を回避できます。
それでも判断に迷うなら、僕はまずCookieセッションを選ぶことをすすめます。
実装がシンプルで、失効もサーバー側で即座に効き、事故ったときのロールバックも簡単だからです。迷ったらCookie、それが結論です。
SPA化やモバイル対応が具体的に決まった段階でJWTへ段階的に移行するほうが、最初からJWTを選んで後から失効やトークン管理の複雑さに苦しむより、結果的に手戻りが少なくなります。
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の認証方式」と位置付けられ、Apple/Google/Microsoftが2022年に共同でパスキー推進を発表し、2023年以降Googleアカウント・Apple ID等の主要サービスで本格導入が進んだことで、2026年現在は認証方式の主流への移行期に入っています。本記事の5方式とは別レイヤーの「ファクタ」で、Cookieセッション や OIDC と組み合わせて利用します（例: パスキーでログイン → セッションCookie発行）。
Q. SSO（シングルサインオン）とOAuthは同じもの？
いいえ、別の概念です。SSOは「1回のログインで複数のサービスを使えるようにする仕組み」全般を指し、OAuth 2.0/OIDCはSSOを実現するための技術手段の1つです。社内システムのSSOにはSAMLが使われることも多く、OAuthはその選択肢の1つという位置づけです。
Q. 基本認証と先進認証（モダン認証）の違いは？
基本認証（Basic認証）はID・パスワードを都度送信する方式、先進認証（モダン認証）はOAuth 2.0をベースにトークンでアクセスを制御し多要素認証（MFA）にも対応した方式です。Microsoft Exchange Onlineは2022年10月以降、基本認証を廃止し先進認証への移行を必須にしました。
