はじめに
こんにちは！kenkenです。
入社したばかりの頃、認証基盤関連の打ち合わせに同席すると、こんな会話が当たり前のように飛び交っていました。
「IdPをどうするか」「SSOはSAMLで？それともOIDC？」「OAuthのフローが…」
……正直、最初は一つひとつの言葉が何を指すのか分からず、会話についていけませんでした。単語ごとに調べてはなんとなく分かった気になり、また忘れる、をくり返していた記憶があります。しかも一度「分かったフリ」で流してしまうと、あとから「それ何ですか？」とは聞きづらくなるんですよね。
そんな「今さら人に聞けない」状態の過去の自分に向けて、この記事を書きました。
結論から先にお伝えすると、この記事では、入社当初の自分が知りたかった認証まわりの略語を6つ（IdP／SSO／MFA／OAuth／OIDC／SAML）、それぞれ「何か」から自分の言葉で整理します。会議やドキュメントで出てきたときの手がかりになれば、という記事です。
読む順番として、以下の「登場人物の役割」で並べると見通しが良くなります。
- 保証する主体 → IdP（認証の元締め）
- 保証の固さ → MFA（確認の要素を増やす）
- 認証の統一 → SSO（さまざまなサービスの認証を1つにまとめる）
- やりとりの規格 → OIDC（認証）、OAuth（認可）、SAML（認証・SSO）
それでは、1つずつ見ていきます。
まず前提：認証まわりの基礎用語
個別の略語に入る前に、土台になる言葉を4つだけ先に押さえておきます。ここが分かると、後の説明がぐっと読みやすくなります。
| 用語 | 意味 |
|---|---|
| 認証（Authentication） | 相手が「誰か」を確かめること。ログイン画面で本人かどうかを確認する、あの行為です。 |
| 認可（Authorization） | 確かめた相手に「何を許すか」を決めること。ログインした後、どの機能・どのデータにアクセスさせるかの話です。 |
| 認証要素 | 本人確認に使う材料。大きく「知識（パスワードなど）」「所持（スマホ・ICカードなど）」「生体（指紋・顔など）」の3種類（NIST SP 800-63B-4）。これを複数使うのが、後で出てくるMFAです。 |
| クレデンシャル（Credential） | ID＋パスワードのような「本人を示す情報」のまとめ。ログイン時に提示する「身分証」のようなものです。 |
とくに認証（誰か）と認可（何を許すか）は別物という点は、このあとのOAuth・OIDCの説明で重要になるので、頭の隅に置いておいてください。
保証する主体：IdP
- IdP（Identity Provider、認証を担う基盤）
- ユーザーが「確かにこの人だ」と保証してくれる、認証の元締めです。ログインのときに「あなたは誰か」を確認し、確認できたことを各サービスに伝える役割を担います。
- IdPはクラウド型もオンプレミス型も含んだ上位の呼び名で、提供形態を問わず「認証を担うもの」の総称です。クラウド型なら Microsoft Entra ID、Okta、Google Workspace（Cloud Identity）など、自社サーバーに立てるオンプレミス型なら AD FS（Active Directory フェデレーション サービス）、Keycloak などが該当します。
- 「IdP」と言われて具体物が浮かばないうちは、「本人確認を引き受ける側」の総称だと思っておくと会議についていけます。
- 出てくる場面：「認証をどこに集約するか」を考えるとき、ID設計の中心として登場します。
⚠️ 混同しやすい語：IdP と IDaaS
| 語 | 意味 |
|---|---|
| IdP | 認証を担う「役割」の呼び名（クラウド／オンプレ両方を含む上位概念） |
| IDaaS（Identity as a Service） | IdP を「クラウドで提供する形態」 |
保証を固くする：MFA
- MFA（Multi-Factor Authentication、多要素認証）
- パスワードに加えて、スマホの通知や生体認証など、複数の要素で本人確認する仕組みです。本人確認そのものの「厳しさ」を上げるもので、「パスワードだけでは危ない」という要件に応えます。使う要素は、基礎用語の「認証要素」で挙げた3種類（知識・所持・生体）から複数を組み合わせます。
- 出てくる場面：セキュリティ要件を検討するとき、「本人確認をどこまで固くするか」の話で登場します。
⚠️ 混同しやすい語：MFA と 二段階認証
| 語 | 条件 | 例 |
|---|---|---|
| MFA（多要素認証） | 要素の「種類」が複数 | パスワード（知識）＋スマホ通知（所持） |
| 二段階認証 | 確認の「回数」が2回（種類は問わない） | パスワード＋秘密の質問（どちらも知識） |
回数を増やすのが二段階認証、種類を増やすのがMFA、と分けて捉えると混ざりません。同じ種類の要素を2回使う二段階認証は、MFAではありません。IPAも、認証を多段で実施する方式を「多段階認証」、記憶情報・所持情報・生体情報のうち2つ以上を用いた方式を「多要素認証」として区別しています。
認証を統一する：SSO
- SSO（Single Sign-On、シングルサインオン）
- ここまでの登場人物を使って、さまざまなサービスの認証を1つにまとめる仕組みです。IdPを認証の中心に置き、後述のSAMLやOIDCといった規格でつなぐことで、一度の認証結果を各サービスで使い回せるようにします。結果として、サービスごとにログインし直す必要がなくなります。
- 裏側では、最初にログインした認証基盤（IdP）が「この人は確認済みですよ」という証明を発行し、各サービスがそれを受け取ってログインを許可しています。
- 出てくる場面：管理側の負荷とリスク軽減の文脈でよく登場します。認証がIdPに集約されるので、サービスごとにアカウントやパスワードを管理する手間が減り、パスワードリセット対応や、退職時のアカウント停止も一元化しやすくなります。
⚠️ 混同しやすい語：SSO と MFA
| 語 | 役割 |
|---|---|
| SSO | 認証の「経路」を1つに統一する |
| MFA | 認証の「要素」を増やして固くする |
軸が違うので、「SSOを入れたからMFAは要らない」にはなりません。むしろSSOは入口を1つにまとめる仕組みなので、その1つが破られると、つながっている全サービスに影響が及びます。入口が1つに集約されるからこそ、そこをMFAで固める意味が増す、という関係です。
やりとりの規格：OIDC・OAuth・SAML
ログインや外部サービス連携の裏側で使われる「規格（プロトコル）」です。それぞれが何かを押さえておきます。
- OIDC（OpenID Connect）
- 「誰か」を確かめる＝認証の規格です。「ログイン（本人確認）」を担うのはこちらです。
- 名前の似たOAuth 2.0とは無関係の別規格、ではありません。仕様上、OIDCはOAuth 2.0の上に認証の層を足したものと定義されています。OAuth 2.0を土台に使い、そこに「誰がログインしたか」を各サービスへ検証可能な形で伝えるしくみを追加した規格、と捉えると関係がつかめます。
- 出てくる場面：「他サービスのアカウントでログインさせたい」ときの標準的な選択肢として登場します。また、IdPと各サービスをOIDCで繋げば、前述のSSO（認証の統一）を実現できます。
- OAuth 2.0（オーオース）
- 「できること（権限）を渡す」＝認可の規格です。たとえば「このアプリに、あなたのカレンダーを読む権限を渡していいですか？」という「権限の受け渡し」を担います。
- 出てくる場面：本人確認（認証）が済んだユーザーが、「自分のデータへのアクセスを、別のアプリにどこまで許すか」を決めて渡す場面で登場します。たとえば、あるアプリに「あなたのカレンダーの読み取りを許可しますか？」と確認画面が出るとき、その裏側で動いているのがOAuthです。
- SAML（サムル、Security Assertion Markup Language）
- SSOを実現するための、歴史ある規格です（XMLベース）。SAML 2.0の仕様が2005年に標準化されて先に普及したため、社内システムや既存のSaaSでの対応が厚く、いまも現役でよく使われています。認証の結果（誰が認証されたか）に加えて、所属や役職などの属性情報も同じ通知の中に一緒に載せられるため、受け取った側のサービスがアクセス可否（認可）を判断する材料にもなります。
- 出てくる場面：既存の業務システムとSSO連携する可否・方式を検討するときに登場します。
⚠️ 混同しやすい語：OAuth と OIDC
| 語 | 役割 |
|---|---|
| OIDC | 認証（誰か）を担う規格 |
| OAuth | 認可（何を許すか）を担う規格 |
認証（誰か＝OIDC）と認可（何を許すか＝OAuth）で担う役割が別もの、とだけ覚えておけば当面は大丈夫です。ただし役割が別なだけで、前述のとおりOIDCはOAuth 2.0を土台にしているので、無関係な2つの規格というわけではありません。
まとめ：6語のおさらい
認証まわりでよく出る略語を、1行ずつでおさらいします。困ったときはここだけ見返せば大丈夫です。
- IdP：本人を保証する認証の元締め（Entra ID／Okta／AD FS など）
- MFA：複数の要素で本人確認を固くする仕組み
- SSO：さまざまなサービスの認証を1つに統一する仕組み
- OIDC：誰かを確かめる＝認証の規格（ログインを担うのはOAuthではなくOIDC。OAuth 2.0の上に認証の層を足したもの）
- OAuth：できること（権限）を渡す＝認可の規格
- SAML：SSOを実現する老舗の規格（XMLベース、既存システムでの対応が厚い）
とくに紛らわしい定番ペアだけ、区別を添えておきます。
SSO ↔ MFA ＝ 経路を統一する ↔ 要素を増やす
OIDC ↔ OAuth ＝ 認証 ↔ 認可
ここが分かれば、認証まわりの会話でつまずくことはかなり減ります。
このシリーズについて
この連載では、ID・セキュリティの略語を「守る対象」で3つの棚に分けて、順に整理していきます。今回（第1話）は、Ⅰの「認証（本人確認）」の入口にあたる回でした。
| 棚 | 守る対象 | 扱う回 |
|---|---|---|
| Ⅰ. ID・アクセス管理 | 人と権限 | 第1話（本記事）・第2話 |
| Ⅱ. ネットワーク防御・境界／検知 | 通信と侵入 | 第3・4話 |
| Ⅲ. クラウド／デバイス統制 | 環境と端末 | 第5話 |
次回（第2話）は、「ログインした後に、何を・どこまで許すか」＝アクセスと権限の話に進みます。
本記事の定義は、各標準仕様・公式資料（RFC 6749、OpenID Connect Core 1.0、OASIS SAML 2.0、NIST SP 800-63B-4、FIDO Alliance 等）に基づいています。
