情報処理試験を勉強していると、「OpenID Connect（OIDC）って、OAuth 2.0と何が違うの？」と混乱しがちです。
認証と認可の違いがあいまいなまま先に進むと、試験本番で選択肢を絞りきれません。
この記事では、OpenID Connectの意味・仕組み・OAuth 2.0やSAMLとの違いを、日常の例え話を交えながら整理します。
対象試験と出題頻度
OpenID Connectは、基本情報技術者・応用情報技術者で出題されるテーマです。
IPAのシラバスVer.7.0（令和6年秋期から適用）で「アイデンティティ連携（OpenID Connect）」が応用情報技術者の出題範囲に明記されました。
今後は午前問題で直接問われる可能性が高い用語です。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★☆☆☆
ランクC（応用）余裕があれば覚える
用語の定義
OpenID Connect（OIDC）とは、一言で言うと
「OAuth 2.0をベースに”認証”の機能を追加した、ユーザーの本人確認をサービス間で安全にやり取りするためのプロトコル」
のことです。
イメージとしては、「身分証明書付きの委任状」のようなものです。
たとえば、新しくスポーツジムに入会するとします。
受付で「会員証を作るので、名前と住所を教えてください」と言われますが、わざわざ一から個人情報を書くのは面倒です。
そこで 「すでに持っている運転免許証を見せるだけで本人確認を済ませ、入会手続きを完了させる」
これがOpenID Connectのやっていることに近い考え方です。
ここで重要なのは、運転免許証は「この人が誰なのか」を証明する機能（＝認証）を持っている点です。
もし渡すのが「この人に車を貸してもいいですよ」という委任状だけだったら、本人確認にはなりません。OAuth 2.0が委任状（認可）だけを扱うのに対し、
OpenID Connectは身分証明書（認証）の仕組みも備えている、という違いがあります。
📊 OpenID Connectの基本情報
| 項目 | 内容 |
|---|---|
| 正式名称 | OpenID Connect（オープンアイディー コネクト）、略称 OIDC |
| 分類 | 認証プロトコル（OAuth 2.0の拡張仕様） |
| 主な用途 | シングルサインオン（SSO）、ID連携（フェデレーション） |
| ベースとなる技術 | OAuth 2.0（認可フレームワーク） |
| 最終仕様の公開 | 2014年2月（OpenID Foundation策定） |
解説
OpenID Connectが生まれた背景には、「OAuth 2.0だけでは本人確認ができない」という課題がありました。
OAuth 2.0はあくまで「認可」のためのフレームワーク、つまり「この人にリソースへのアクセスを許可してよいか」を扱う仕組みです。しかし実際のWebサービスでは、「この人は誰なのか」を確認する「認証」も同時に必要になります。
そこで、OAuth 2.0の認可フローにIDトークンという認証用のデータを追加する形で標準化されたのが、OpenID Connectです。
「認証」と「認可」の違い
OpenID Connectを正しく理解するには、「認証」と「認可」を区別することが絶対条件です。
この2つを混同すると、OAuth 2.0との違いが永遠にわかりません。
📊 認証と認可の違い
| 比較項目 | 認証（Authentication） | 認可（Authorization） |
|---|---|---|
| 問い | 「あなたは誰ですか？」 | 「あなたに何を許可しますか？」 |
| 例え | パスポートを見せて本人確認する | 入場チケットを見せて会場に入る |
| 英語の略 | AuthN | AuthZ |
ここだけは確実に押さえてください。
「認証＝本人確認」「認可＝権限の付与」です。OAuth 2.0は認可だけ、OpenID Connectは認証＋認可の両方を扱います。
OpenID Connectの認証フロー（認可コードフロー）
最も代表的な処理の流れである「認可コードフロー」を整理します。登場人物は3者です。
📊 登場人物と処理の流れ
| 順序 | 動作 | 内容 |
|---|---|---|
| 1 | 利用者→RP | 利用者がRP（Relying Party＝サービス提供者）にアクセスし、「Googleでログイン」などを選択する |
| 2 | RP→OP | RPが利用者をOP（OpenID Provider＝認証を行う側、GoogleやMicrosoftなど）にリダイレクトする |
| 3 | 利用者⇔OP | OPが利用者の認証（ID・パスワード入力など）を行い、認可コードを発行する |
| 4 | RP→OP | RPが認可コードをOPに送り、IDトークンとアクセストークンを受け取る |
| 5 | RP | RPがIDトークンを検証し、利用者の本人性を確認してサービスを提供する |
ポイントは手順4で発行されるIDトークンです。
これはJWT（JSON Web Token）形式で記述された認証情報であり、「誰が」「いつ」「どこで」認証されたかを含んでいます。OAuth 2.0にはこのIDトークンが存在しません。
OpenID Connectが「OAuth 2.0に認証を足した仕組み」と言われる理由は、このIDトークンの有無に集約されます。
OAuth 2.0・SAMLとの比較
試験の選択肢でよく並ぶ3つの技術を整理します。
📊 OIDC・OAuth 2.0・SAMLの比較
| 項目 | OpenID Connect | OAuth 2.0 | SAML |
|---|---|---|---|
| 目的 | 認証＋認可 | 認可のみ | 認証＋認可 |
| データ形式 | JSON（JWT） | JSON | XML |
| 主な用途 | WebアプリやモバイルアプリのSSO | APIアクセスの権限委譲 | 企業間のSSO |
| 関係性 | OAuth 2.0の拡張 | OIDCの土台 | 独立した別規格 |
最大の区別ポイントは、OAuth 2.0が「認可だけ」であるのに対し、OpenID ConnectとSAMLは「認証もできる」という点です。
OpenID ConnectとSAMLの違いは、データ形式と適用場面にあります。
OIDCはJSON/JWTベースで軽量なためWebサービスやモバイルとの親和性が高く、SAMLはXMLベースで企業のイントラネット間連携に強みを持っています。
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 OpenID Connectの核心を3行で
・OAuth 2.0に「IDトークン」による認証機能を追加した拡張プロトコル
・OAuth 2.0は「認可（何を許可するか）」のみ、OIDCは「認証（誰なのか）＋認可」の両方を扱う
・「Googleでログイン」のようなソーシャルログインの裏側で動いている技術
試験ではこう出る！
OpenID Connectは、IPAのシラバスVer.7.0（令和6年10月適用）で応用情報技術者の「情報セキュリティ」分野に「アイデンティティ連携（OpenID Connect）」として追加された比較的新しい出題対象です。
基本情報・応用情報の午前問題では、シラバス改訂後に直接的な出題がまだ少ない段階ですが、上位試験の情報処理安全確保支援士ではすでに繰り返し出題されています。
📊 関連する過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| 支援士 R4春 午後Ⅱ 問2 |
クラウドサービスへの移行をテーマとし、OIDCを用いたサービス間のID連携が出題。認可コードフローの流れや、nonceによるリプレイ攻撃対策が問われた。 | ・OIDCの認可コードフロー ・nonce（リプレイ攻撃対策） ・OAuth 2.0との関係 |
| 支援士 R6秋 午前Ⅱ 問8 |
SSO方式（SAML・エージェント・代理認証・リバースプロキシ）の特徴を問う問題。解説でOIDCが「認証連携方式」のひとつとして位置付けられている。 | ・各SSO方式の正確な区別 ・OIDCはSAMLと並ぶ認証連携技術 |
| 支援士 R5秋 午前Ⅱ 問14 （R7春 問16で再出題） |
OAuth 2.0の説明として適切なものを選ぶ問題。「認可のみで認証は行わない」が正解のポイント。解説で「認可も認証も行うものにはOpenID Connectがある」と言及。 | ・OAuth 2.0は認可専用 ・認証を行うのはOIDC |
支援士R5秋 午前Ⅱ 問14では、「OAuth 2.0は認証を行うプロトコルである」という選択肢がひっかけとして出題されました。
OAuth 2.0は認証ではなく認可のプロトコルであり、認証もカバーするのがOpenID Connectです。
この区別は基本情報・応用情報でもそのまま問われる可能性が高いので、割り切って覚えてしまいましょう。
【頻出キーワード】
- IDトークン（JWT形式の認証情報）
- 認証と認可の違い（AuthN vs AuthZ）
- OAuth 2.0の拡張仕様
- RP（Relying Party）＝サービス提供者
- OP（OpenID Provider）＝認証を行う側
- 認可コードフロー
試験問題で「OAuth 2.0を拡張し、IDトークンを用いてユーザーの認証を行うプロトコル」や「認可コードの検証後にIDトークンとアクセストークンを受け取り、利用者の本人性を確認する認証連携の仕組み」といった記述があれば、それは「OpenID Connect」を指しています。
📝 IPA試験での出題パターン
午前問題では「OAuth 2.0の説明として適切なものを選べ」という形式で間接的にOIDCとの区別が問われるパターンが定番です。
ひっかけ選択肢として「OAuth 2.0は認証を行うプロトコルである」が頻出なので、「OAuth 2.0＝認可のみ」「OIDC＝認証＋認可」を反射的に判別できるようにしてください。
午後問題では、支援士レベルで認可コードフローの手順やnonce・stateパラメータの役割が記述式で問われています。基本情報・応用情報では深追い不要ですが、「IDトークン」「RP」「OP」という用語は選択肢に登場する可能性があります。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. OpenID Connect（OIDC）に関する説明として、最も適切なものはどれでしょうか？
- A. リソースオーナーの許可のもと、サードパーティにリソースへのアクセス権限を付与する認可専用のフレームワークである
- B. IdPが利用者の認証結果をXML形式のアサーションとしてSPに送信することでSSOを実現する方式である
- C. OAuth 2.0の認可フローにIDトークンを追加し、サービス間でユーザーの認証情報を安全にやり取りするプロトコルである
正解と解説を見る
正解：C
解説：
OpenID Connect（OIDC）は、OAuth 2.0の認可フローにIDトークン（JWT形式）を追加することで、サービス間でユーザーの本人確認情報を安全にやり取りできるようにしたプロトコルです。支援士R5秋 午前Ⅱ 問14でも「認可も認証も行うものにはOpenID Connectがある」と明記されており、「OAuth 2.0＋認証」という位置付けが正確な理解です。
選択肢Aは「OAuth 2.0」の説明です。OAuth 2.0は認可のみを扱うフレームワークであり、認証機能を持ちません。選択肢Bは「SAML（Security Assertion Markup Language）」の説明です。SAMLはXML形式のアサーションを用いてSSOを実現する方式であり、JSON/JWTベースのOIDCとはデータ形式や設計思想が異なります。
よくある質問（FAQ）
Q. 「Googleでログイン」「Apple IDでサインイン」はOpenID Connectですか？
はい、Google・Apple・Microsoftなどが提供する「ソーシャルログイン」の多くはOpenID Connectを採用しています。ユーザーが外部サービスのアカウントを使って別のWebサービスにログインする際、裏側でIDトークンがやり取りされ、本人確認が行われています。実務でWebサービスを開発する際にも頻繁に登場する仕組みです。
Q. OpenID ConnectのIDトークンには具体的に何が入っていますか？
IDトークンはJWT（JSON Web Token）形式で記述され、主にユーザー識別子（sub）、トークン発行者（iss）、対象サービス（aud）、発行日時（iat）、有効期限（exp）などのクレーム（属性情報）が含まれています。トークン自体にデジタル署名が付与されているため、RP側で改ざんの有無を検証できます。試験では「JWT」「署名付きトークン」というキーワードとセットで覚えておくと対応しやすくなります。
Q. OpenID Connect以前の「OpenID」とは何が違いますか？
初代のOpenID（OpenID 2.0）は、URL形式の識別子を使ってユーザーを認証する仕組みでした。しかし実装の複雑さやモバイル対応の弱さから普及が限定的でした。OpenID Connectは名前こそ引き継いでいますが、技術的にはOAuth 2.0をベースに完全に再設計されたものであり、旧OpenIDとは別物と考えて問題ありません。
Q. 「nonce」や「state」パラメータは試験に出ますか？
基本情報・応用情報レベルでは深追い不要です。ただし支援士試験では、支援士R4春 午後Ⅱ 問2でnonceの役割（リプレイ攻撃の防止）が問われた実績があります。nonceは「Number used once（一度だけ使う数値）」の略で、トークンの使い回しを防ぐためのパラメータです。stateはCSRF対策に使われます。支援士を目指す方はこの2つも押さえておくと安心です。
