--- title: "トークン認証とは？SAML・OAuth・OIDCの違いを整理【SG試験】" description: "トークン認証を認証結果や権限情報を受け渡す仕組みとして整理し、SAML、OAuth、OIDCが担うSSO、認可、本人情報連携の違いをIdPとの関係から見分けます。ログイン連携、API利用許可、IDトークンの目的を混同せず、どの情報を誰に渡す仕組みかで判断します。" last_modified_at: "2026-06-29" canonical_url: "https://stemtazoo.github.io/sg/token-authentication/" section: "sg" --- ## まず結論 トークン認証とは、認証結果をトークンとして受け渡し利用する仕組みであり、SG試験では「何をやりたい仕組みか（認証か認可か）」を見抜くことが重要です。 --- ## 直感的な説明 SSOでは、毎回パスワードを入力する代わりに👇 👉 「この人は認証済みです」という証明書（トークン）を使い回します --- イメージ👇 - 入館証を見せれば各部屋に入れる → 毎回本人確認しない 👉 **認証結果を持ち回る仕組み** --- ## 定義・仕組み トークン認証は、認証後に発行されたトークンを使って、他のシステムへのアクセスを可能にする仕組みです。 --- ### ■ 基本の流れ 1. IdPで認証 2. トークンを発行 3. 他システムに提示してアクセス 👉 **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を優先。 - 迷ったら「誰を確認するか＝認証」「何を許すか＝認可」で選択肢を切る。