Web認証方式5種類の違いを比較｜JWT・OAuthの使い分け

Web認証とは、WebサイトやWebアプリにアクセスしてきた相手が本人かどうかを、サーバーが確かめる仕組みです。

方式は大きく2つの世代に分かれます。リクエストのたびにIDとパスワードを送る古い方式（レガシー認証）と、一度の本人確認で発行したトークンを使い回す新しい方式（モダン認証）です。

Microsoft 365の管理画面で「基本認証は終了、先進認証へ移行」と告げられて、この記事にたどり着いた人もいるでしょう。その場合はレガシー認証とモダン認証の違いから読むと早いです。メール送信に使うSMTP AUTHの基本認証は、2026年12月末に既定で無効になる予定です。

Basic認証からOAuth 2.0、OpenID Connect、パスキーまで、仕組みの違いと使い分けを順に整理します。

Web認証とは？認証と認可の違い

Web認証とは、リクエストを送ってきた相手が誰なのかをサーバーが確認し、その結果を以降の通信に引き継ぐ仕組みです。

確認するのは「誰か」だけで、「何をしてよいか」は別の話になります。

この2つを混ぜたまま方式を比べると、OAuthが認証なのか認可なのかで必ず迷います。

先に用語を分けておきます。

認証（Authentication）と認可（Authorization）

認証は「あなたは誰ですか」を確かめる工程、認可は「その人に何を許すか」を決める工程です。

ログイン画面でIDとパスワードを入れるのが認証で、ログイン後に管理画面を開けるかどうかを決めるのが認可に当たります。

オフィスに例えると、受付で社員証を見せて本人だと確かめるのが認証、本人と分かった上で「あなたが入れるのは3階まで」と決めるのが認可です。

401と403の使い分けは、HTTPステータスコード一覧にまとめています。

OAuth 2.0が認可の仕様である点は、後の章で扱います。

認証の3要素と多要素認証（MFA）

本人確認の材料は、3種類に分けられます。

多要素認証（MFA）とは、この3種類のうち異なる2つ以上を組み合わせる方式です。

パスワードと秘密の質問は、どちらも「知識」なので多要素になりません。

パスワードとスマートフォンのワンタイムコードなら、知識と所持の組み合わせで多要素です。

認証方式の種類を一覧で比較

Webで使われる認証方式は、本人確認の材料をどう送るかで整理すると、違いが見えます。

表の前に、方式を4つの考え方に分けた地図を置きます。

パスワードを毎回送る方式と、署名やトークンで証明する方式に大きく分かれ、後者がモダン認証の中心になります。

地図を頭に入れたうえで、方式ごとの違いを表で確かめます。

世代の列は、次の章で説明する線引きに従っています（フォームとセッションCookieは、毎回パスワードを送らない点でモダン寄りですが、ブラウザ向けの定番として「現役」と書いています）。

もう1つ、選ぶときに効く「安全性」の観点でも並べます。

「実装の重さ」は目安です。OAuth 2.0・OpenID Connect・SAMLは、自作せずに既存のサービスやライブラリに任せる前提で考えると、負担は大きく下がります。

レガシー認証とモダン認証（先進認証）の違い

レガシー認証とモダン認証の違いは、一言で言えば「毎回パスワードを渡すか、本人確認の結果として発行された期限付きの証明を渡すか」です。

同じ言葉でも文脈で指す範囲が違うので、一般論とMicrosoftの用語を分けて押さえます。

後者は、Microsoft 365やExchange Onlineの管理者が実際に直面する話です。

一般的な違い

比較軸を並べると次のとおりです。

トークンを使えば安全、と短絡はできません。

トークンの保存先を誤ればXSSで抜かれますし、署名の検証を省けば偽造されます。

モダン認証の利点は、被害の範囲と期間を設計で絞れる点にあります。

Microsoftの「基本認証」「レガシー認証」「先進認証」

Microsoft Learnの日本語版では、モダン認証が「先進認証」「最新の認証」と訳されていて、表記が揺れています。

どちらも英語のModern Authenticationを指します。

Microsoftの文脈での対応は、次のとおりです。

MicrosoftはMicrosoft Learnで、先進認証を次の3つの組み合わせとして説明しています。

先進認証は単体の技術名ではなく、複数の仕組みを束ねた総称です。

検索で「先進認証とは」と調べて要領を得ないのは、この総称という性格のせいでしょう。

Exchange Onlineで基本認証が使えなくなった経緯

基本認証は、Exchange Onlineではすでに廃止済みです。

Microsoft Learnによると、21Vianet運営版を除く環境では、2022年10月1日から無効化が始まりました。

現在はすべてのテナントで基本認証が無効です。

対象は、Exchange ActiveSync、POP、IMAP、リモートPowerShell、Exchange Webサービス、オフラインアドレス帳、自動検出、Outlook for WindowsとMacです。

こうしたプロトコルは、OAuth 2.0トークンベースの承認を使う方式への移行が求められています。

Microsoftが基本認証を止めた根拠は、攻撃の統計に表れています。

Microsoft Learnには、資格情報スタッフィング攻撃の97%以上、パスワードスプレー攻撃の99%以上がレガシー認証を利用している、というMicrosoftの分析が掲載されています。

同じページによれば、これらの攻撃は基本認証を無効化またはブロックすると止まります。

SMTP AUTH（メールソフトや業務システムがメールを送るときの認証）だけは別扱いです。

使われていないテナントでは無効化されましたが、使われているテナントでは今も基本認証で送信できます。

Microsoftは2026年1月、SMTP AUTHの基本認証を止める予定を次のように更新しました（Exchange Team Blog）。

• 2026年12月まで：今までどおり基本認証で送信できる
• 2026年12月末：既存のテナントで既定で無効になる。管理者が設定で有効に戻すことはできる
• 2026年12月末より後に作るテナント：最初から基本認証は使えず、OAuthが前提になる
• 2027年後半：最終的な廃止日が発表される予定

当初の予定（2026年3月から拒否を始め、4月末に完全に止める）からは後ろにずれています。

複合機のスキャン送信や監視ツールの通知など、ユーザー名とパスワードでメールを送っている仕組みがあるなら、12月末より前にOAuthへの切り替えか、Microsoft Graph APIのsendMailへの移行を検討してください。

予定はこれまでも変わってきたので、作業の前に公式の発表で最新の日付を確かめてください。

自分のテナントでレガシー認証を洗い出す手順

レガシー認証が残っているかどうかは、サインインログで調べられます。

管理者が実際に行う流れは、次のとおりです。

1. Microsoft Entra管理センターで、サインインログを開く
2. 「クライアントアプリ」列を表示し、レガシー認証プロトコルでフィルターする
3. 「ユーザーサインイン（非対話型）」タブも同様に確認する
4. 使っているクライアントとユーザーを特定し、OAuth対応版へ移行する
5. 条件付きアクセスで「Exchange ActiveSyncクライアント」と「その他のクライアント」を対象にブロックポリシーを作る

ブロックポリシーは、最初に「レポート専用」で作ります。

影響範囲を確認してから「オン」に切り替えれば、業務で使っている接続を巻き込むリスクを抑えられます。

ロックアウトを避けるため、緊急アクセス用アカウントを除外対象に入れておくのもMicrosoftの推奨です。

Basic認証とDigest認証：パスワードを毎回送る方式

Basic認証とDigest認証は、HTTPの仕様に標準で含まれる最も古い認証方式です。

どちらもリクエストごとに本人確認の材料を送るため、レガシー認証に分類されます。

部屋に入るたびに社員番号を口頭で伝えるようなもので、聞かれてしまえば誰でも使い回せます。

今から新しいサービスで採用する場面は少なくなりましたが、既存システムの保守や、開発用サイトの簡易な保護では今も出会います。

Basic認証（RFC 7617）

Basic認証とは、ユーザーID:パスワード をBase64（データを英数字だけの文字列に置き換える変換）で変換し、Authorization ヘッダーに入れて送る方式です。

仕様はRFC 7617（2015年9月）で定められています。RFCはインターネット技術の仕様書で、番号で呼ばれます。

サーバーは未認証のリクエストに401と WWW-Authenticate ヘッダーを返し、ブラウザがIDとパスワードの入力ダイアログを出します。

GET /admin HTTP/1.1
Host: example.com
Authorization: Basic dXNlcjpwYXNz

dXNlcjpwYXNz は、user:pass をBase64で変換しただけの文字列です。

Base64は暗号化ではなく、誰でも元に戻せます。

RFC 7617自身が、TLSなどの外部のセキュアな仕組みと組み合わせない限り、安全な認証方法とは考えられないと明記しています。

弱点をまとめます。

使ってよいのは、HTTPSを前提にした開発用サイトの目隠しなど、漏れても被害が限られる場面です。

ユーザー情報を扱う本番のログインには向きません。

Digest認証（RFC 7616）

Digest認証とは、パスワードそのものではなく、サーバーが発行した使い捨ての値（nonce）とパスワードから計算したハッシュ値（元のパスワードに戻せない形に変換した値）を送る方式です。

仕様はRFC 7616（2015年9月）で、従来のRFC 2617を置き換えています。

パスワードが平文で流れない点がBasic認証に対する改善です。

RFC 7616はハッシュにSHA-256とSHA-512/256を対応させ、MD5は後方互換のためだけに残しています。

ただしサーバーはハッシュ計算のために、パスワードか、それに相当する値を持っている必要があります。

bcryptのような遅いハッシュで保存する現代のパスワード管理と相性が悪く、仕様自身もパスワードファイルの保護を求めています。

そのため、新規の設計で選ばれる場面はほぼありません。

セッションCookieとJWT：ログイン後の状態をどう持つか

ブラウザ向けのWebアプリが現役で使う認証は、ログイン時にIDとパスワードを確認し、以後は別の目印で本人を識別する形です。

その目印をサーバーが覚えておくのがセッション、署名付きの文字列にしてクライアントが持つのがJWTです。

どちらを選ぶかで、ログアウトの扱いやスケールの考え方が変わります。

受付で入館証をもらう場面に置き換えると、受付が入館証の控えを持つのがセッション、控えは持たず偽造できない印だけで確かめるのがJWTです。

フォーム認証＋セッションCookie

フォーム認証＋セッションCookieとは、ログインフォームでパスワードを確認し、サーバーが発行したセッションIDをCookieで持たせる方式です。

サーバーはセッションIDをキーに、ユーザー情報をメモリやRedisなどに保存します。

ブラウザは以降のリクエストにCookieを自動で付けるので、アプリ側のコードは単純になります。

Set-Cookie: SESSIONID=a1b2c3d4; Path=/; Secure; HttpOnly; SameSite=Lax

Cookieには属性を付けます。

サーバー側で状態を持つので、強制ログアウトや端末の切り離しが即座にできます。

一方で、ログイン成功の直後にセッションIDを必ず再発行しないと、事前に仕込まれたIDで乗っ取られる（セッション固定攻撃）危険が残ります。

Javaで組む場合の実装は、Spring Security入門で詳しく扱っています。

トークン認証とJWT（RFC 7519）

JWT（JSON Web Token）とは、ユーザーの情報（クレーム）をJSONで持たせ、デジタル署名（改ざんされていないことを確かめる印）を付けた文字列です。

仕様はRFC 7519で、ヘッダー.ペイロード.署名 の3つをピリオドでつないだ形をとります。

サーバーは署名を検証するだけで本人性を確かめられるので、セッションの保存先を持たずに済みます。

{
  "sub": "user-1234",
  "iss": "https://auth.example.com",
  "aud": "my-api",
  "iat": 1790000000,
  "exp": 1790000900
}

上はペイロードの例です。

exp が有効期限で、この例は発行から900秒（15分）です。

APIを呼ぶときは、トークンを Authorization: Bearer <トークン> で送ります。

JWTの弱点は、発行済みのトークンを途中で取り消しにくい点です。

サーバーが状態を持たない代わりに、有効期限が来るまでは検証を通り続けます。

対策は、アクセストークンの有効期間を短くし、更新用のリフレッシュトークンを別に管理する構成が定番です。

保存先も判断が分かれます。

localStorage に置くとXSSで読み取られるので、ブラウザではHttpOnlyのCookieに入れる設計のほうが安全側です。

署名の検証では、アルゴリズムの指定をトークンのヘッダーに任せないのも基本です。JWTの安全な使い方はRFC 8725にまとまっています。

セッションとJWTの比較

「JWTのほうが新しいから良い」ではありません。

ブラウザで同一ドメインのWebアプリなら、セッションCookieのほうが失効の面で扱いやすいケースが多数です。

OAuth 2.0・OpenID Connect・SAML・パスキー

ここからは、自分のサービスでパスワードを預からない方式です。

外部サービスへの権限委譲、外部IDでのログイン、企業のシングルサインオン、パスワードレスの4つを順に扱います。

似た名前が多いので、「何を決める仕様か」で切り分けます。

たとえると、OAuth 2.0は合鍵を貸す仕組み、OpenID Connectは「この人は本人です」と書いた紹介状、SAML 2.0は企業間で使う紹介状、パスキーは本人の端末にだけある鍵です。

OAuth 2.0は認可、OpenID Connectは認証

OAuth 2.0（RFC 6749）とは、ユーザーのパスワードを渡さずに、アプリに限定的なアクセス権を与える認可の仕様です。

「このアプリに、私のGoogleカレンダーの読み取りだけを許可する」といった場面に使います。

アプリが受け取るのはアクセストークンで、本人が誰かを証明するものではありません。

OpenID Connect（OIDC）とは、OAuth 2.0の上に本人確認の仕組みを足した仕様です。

認可サーバー（トークンを発行する側）はアクセストークンに加えてIDトークン（JWT形式）を返し、アプリは「誰がログインしたか」を知れます。

「Googleでログイン」は、このOIDCで動いています。

Authorization Code＋PKCEの流れ

現在の標準フローは、認可コードを経由するAuthorization Code Flowです。

認可コードは、ブラウザ経由で届く1回限りの引換券にすぎません。

アプリはそれをバックエンドから認可サーバーへ送り、トークンと交換します。

動きで追いたい人向けに、人・アプリ・認可サーバーのやりとりをアニメにしました。

止めて読みたいときは、下の静止した図を見てください。

アプリはリクエストごとにランダムな code_verifier を作り、そのハッシュ値（code_challenge）を最初に送ります。

コードを交換するときに元の値を示せなければ、トークンは渡されません。

OAuth 2.0のセキュリティ上のベストプラクティスは、2025年1月にRFC 9700としてまとまりました。

RFC 9700は、認可サーバーにPKCEのサポートを求め、公開クライアントにはPKCEの使用を求めています。

一方でImplicit grantは使わないことを推奨（SHOULD NOT）しています。

Resource Owner Password Credentials grantは、使ってはならない（MUST NOT）扱いです。

古い解説記事にあるImplicit Flowやパスワード付与は、現在は避ける方式です。

SAML 2.0とパスキー（WebAuthn）

SAML 2.0とは、XMLのアサーション（本人確認済みの証明書）をIdP（ID提供側）からサービス提供側へ渡して、シングルサインオンを実現する仕様です。

2005年にOASISが標準化した企業向けの仕様で、社内ポータルやSaaSの連携に今も使われます。

新規でログインを組むならOIDCのほうが扱いやすく、SAMLは取引先の要件で必要になる場面が中心です。

パスキーとは、WebAuthnとFIDOの仕様に基づく、公開鍵暗号を使ったパスワードレス認証です。

登録時に端末の中で秘密鍵と公開鍵のペアを作り、公開鍵だけをサーバーに預けます。

ログイン時はサーバーが出した課題（チャレンジ）に、端末が秘密鍵で署名して返すので、パスワードもその代わりになる値もネットワークを流れません。

パスキーが強いのは、鍵が登録したサイトのドメインに結び付く点です。

偽サイトでは署名が作られず、フィッシングに引っかかりません。

パスワード認証を残す場合も、MFAとあわせて段階的にパスキーへ寄せていく方針が現実的です。

用途別の選び方：判断フロー

選ぶときは、方式の新旧より先に「誰がどこからログインするか」を決めます。

自社でIDを持つのか、外部のIDを使うのか。クライアントがブラウザ中心なのか、モバイルや別ドメインのAPIなのか。

この分岐をたどると、候補は2〜3個に絞れます。

状況別の対応を表にします。

メールシステムなどMicrosoft 365と連携する側は、方式を選ぶ立場ではなく、基本認証をやめてOAuth 2.0に対応する立場です。

POPやIMAPで基本認証に依存したクライアントは、OAuth 2.0対応版への更新か、別の接続手段への移行が求められます。

よくある質問

Web認証と、レガシー認証・モダン認証の違いについて、よく聞かれる質問をまとめました。

Q1. Web認証とは何ですか？

A1. Webサイトやアプリにアクセスした相手が本人かどうかを、サーバーが確かめる仕組みです。パスワード、トークン、生体、公開鍵暗号など、本人確認の材料の違いで方式が分かれます。

Q2. レガシー認証とモダン認証の違いは何ですか？

A2. レガシー認証はリクエストごとにID・パスワードを送る方式で、MFAを組み込みにくい特徴があります。モダン認証は認証サーバーで本人確認し、期限付きのトークンを使う方式で、MFAや条件付きアクセスを足せます。

Q3. 基本認証と先進認証の違いは何ですか？

A3. 基本認証はユーザー名とパスワードを毎回送る方式で、Exchange Onlineでは廃止済みです（SMTP AUTHだけは2026年12月末に既定で無効になる予定）。先進認証はMicrosoftの用語で、MFAなどの認証方法、OAuthによる承認、条件付きアクセスを束ねた総称です。

Q4. JWTとセッションCookieはどちらを選ぶべきですか？

A4. ブラウザ中心のWebアプリならセッションCookieが扱いやすく、強制ログアウトも即時にできます。モバイルアプリや複数のAPIをまたぐ構成なら、短命なトークン（JWTなど）が向きます。

Q5. OAuthとOpenID Connectは何が違いますか？

A5. OAuth 2.0は権限を渡す認可の仕様で、アクセストークンを発行します。OpenID ConnectはOAuth 2.0にIDトークンを足して、誰がログインしたかを確認できるようにした認証の仕様です。

Q6. JWTをlocalStorageに保存するのは危険ですか？

A6. XSSの脆弱性があると、JavaScriptから読み取られてトークンを盗まれます。ブラウザで扱うなら、HttpOnly属性を付けたCookieに入れる設計のほうが抜き取られにくくなります。

Q7. Basic認証は今でも使ってよいですか？

A7. HTTPSを前提に、検証サイトの目隠しなど漏れても被害が小さい場面なら使えます。ユーザー情報を扱う本番のログインや、MFAが必要な場面には向きません。

Web認証の方式選びのまとめ

Web認証は、毎回パスワードを送る世代から、期限付きトークンと公開鍵暗号を使う世代へ移っています。

Microsoftが基本認証を止めたのも、この流れの一部です。

2026年10月時点で、RFC（7617・7616・7519・6749・9700）とMicrosoft Learnを突き合わせて書いています。

認証を自作する場面は減っています。

ログインを組むときは、まずOIDCの外部IdPやフレームワークの標準機能に任せられないかを検討してください。

Javaで試すなら、Spring Security入門から始めるのが近道です。

HTTPS側の仕組みは、TLSの仕組みで図解しています。

途中経過は、また書きます。