トークン認証とは？SAML・OAuth・OIDCの違いを整理【SG試験】

まず結論

トークン認証とは、認証結果をトークンとして受け渡し利用する仕組みであり、SG試験では「何をやりたい仕組みか（認証か認可か）」を見抜くことが重要です。

直感的な説明

SSOでは、毎回パスワードを入力する代わりに👇

👉 「この人は認証済みです」という証明書（トークン）を使い回します

イメージ👇

入館証を見せれば各部屋に入れる
→ 毎回本人確認しない

👉
認証結果を持ち回る仕組み

定義・仕組み

トークン認証は、認証後に発行されたトークンを使って、他のシステムへのアクセスを可能にする仕組みです。

■ 基本の流れ

IdPで認証
トークンを発行
他システムに提示してアクセス

👉
SSOの実現に使われる

どんな場面で使う？

■ 使う場面

SSO
クラウドサービス連携
API連携

👉 SG試験では
「SSOの裏で使われる仕組み」として出ることがあります。

よくある方式（SGレベルでOK）

■ SAML（サムル）

認証情報をやり取りする仕組み
主に企業向けSSO

👉
認証（SSO）で使う

■ OAuth（オーオース）

他サービスへのアクセス権を委譲する仕組み

👉 例
「Googleアカウントでログインして、別サービスにアクセス」

👉
認可（権限付与）の仕組み

■ OpenID Connect（OIDC）

OAuthを拡張して「認証」もできるようにしたもの

👉
認証＋認可ができる

どんな場面で使う？

■ 使い分け（重要）

方式	役割
SAML	認証（SSO）
OAuth	認可（権限委譲）
OIDC	認証＋認可

👉
「何をしたいか」で判断する

OAuth2.0の役割対応（どの設問でも使える切り分け）

OAuth2.0の設問では、サービス名や人物名ではなく、役割に置き換えると選択肢を切りやすくなります。

OAuth2.0の役割	何をする？	設問での言い換え例
リソースオーナー	自分のデータへのアクセス可否を同意する	利用者、ユーザー本人、データ所有者
クライアント	同意を得てAPIを利用する	連携アプリ、外部Webサービス、サードパーティアプリ
認可サーバ（＋リソースサーバ）	認可後にアクセストークンを発行し、要求を検証する	API提供側サービス、プラットフォーム側サービス

■ このタイプの問題で最重要の1点

アクセストークンを発行するのは、認可サーバ側です。

クライアントは、発行されたトークンを受け取って使う側
リソースオーナーは、アクセス可否を同意する側

■ SG試験でのひっかけ（OAuth2.0フロー版）

「クライアントがアクセストークンを発行する」 → ❌ 誤り（発行は認可サーバ）
「OAuthでは利用者のデジタル証明書授受が中心」 → ❌ 誤り（基本は認可とトークン授受が中心）

👉 判断基準
発行するのはどこか（認可サーバ）／使うのはどこか（クライアント）を先に確認する。

よくある誤解・混同

❌ OAuthは認証の仕組み

→ ⭕ 認可（権限付与）

❌ SAMLとOAuthは同じ

→ ⭕ 役割が違う

❌ OIDCは別物で難しい

→ ⭕ OAuthの拡張

■ SG試験でのひっかけ

「外部サービスにアクセス許可」
→ OAuth
「SSOでログイン」
→ SAML または OIDC

👉
認証か認可かで判断する

確認問題（SG試験対策）

トークン認証の説明として最も適切なものはどれか。

ア. 毎回ID/パスワードを平文送信する方式である。
イ. 認証後に発行されたトークンを用いて、後続アクセスを検証する方式である。
ウ. 認可情報は含められず、用途はログ記録だけである。
エ. トークンは漏えいしても不正利用されない。

▶ クリックして答えと解説を見る（ここを開く）

正解：イ

解説

ア：トークン認証の趣旨と逆です。
イ：セッション管理やAPI認証で広く使われます。
ウ：方式によっては権限情報を保持できます。
エ：漏えい対策（短寿命化・失効管理）が重要です。

👉 判断ポイント
トークンは「認証後の証票」。漏えい前提の保護設計が必要。

まとめ（試験直前用）

先に「本人確認の話か」「権限委譲の話か」を判定する。
トークン認証は、認証後に発行した証票で再入力を減らす仕組み（漏えい前提で短寿命・失効管理が重要）。
SAML/OIDCが中心なら認証（SSO）寄り、OAuthが中心なら認可（権限委譲）寄り。
「外部アプリに代理アクセスさせる」文脈ならOAuth、「ログイン連携で本人確認」ならSAML/OIDCを優先。
迷ったら「誰を確認するか＝認証」「何を許すか＝認可」で選択肢を切る。

🔗 関連記事

🏠 情報セキュリティマネジメントトップに戻る