「OAuthで認証機能を実装する」「SSOとSAMLはどう違う？」
Web開発や情シス業務に携わっていると、このような会話の中で用語が混ざってしまい、混乱することは珍しくありません。ログイン周りの用語は、言葉の響きが似ていても「指しているレイヤー（階層）」がまったく異なります。
結論から言うと、これらは以下のように分類することでスッキリ整理できます。
- 認証・認可：行為の定義（誰か？ 何ができるか？）
- SSO：ユーザーが得られる便利な「体験」
- フェデレーション：システム同士の信頼の「仕組み」
- OAuth / OIDC / SAML：情報を受け渡すための「ルール（規格）」
この記事では、混同しがちなログイン周りの用語を、なるべく分かりやすく紐解いていきます。
認証(Authentication)と認可(Authorization)の違い：すべての基礎
まず最初に区別しなければならないのが、「認証（Authentication / AuthN）」と「認可（Authorization / AuthZ）」の違いです。英単語も似ていますが、セキュリティの観点では明確に役割が分かれています。
認証（AuthN）は、「あなたが誰であるか」を確認するプロセスです。
IDとパスワードの入力、生体認証、多要素認証などがこれにあたります。システムが「この操作をしているのは、間違いなく登録されている田中さん本人だ」と特定する作業と言い換えられます。
認可（AuthZ）は、「あなたが何をしてよいか」という権限を与えるプロセスです。
たとえ本人確認（認証）が済んでいても、管理者権限がなければ設定画面には入れません。この「アクセス権限の制御」が認可です。
分かりやすい例として、ホテルのチェックインを想像してみてください。
フロントで身分証を見せて本人確認をするのが「認証」。そこで渡されたカードキーを使って、特定の部屋やラウンジだけに入れるようにするのが「認可」です。Webシステムでの「401エラー（認証が必要）」と「403エラー（権限不足）」の違いも、この概念に基づいています。
シングルサインオン(SSO)とフェデレーション：体験と仕組み
次に整理すべきなのが、SSO（シングルサインオン）とフェデレーションの関係です。これらは対立する言葉ではなく、「目的」と「手段」に近い関係性を持っています。
SSOは、ユーザー視点の「体験」を指す言葉です。
一度のログイン処理だけで、メール、チャット、勤怠管理など、複数の異なるサービスを利用できる状態を指します。ユーザーにとっては「パスワードを何回も入力しなくて済む」「パスワード管理の手間が減る」というメリットがあります。
一方、フェデレーションはシステム視点の「信頼の仕組み」です。
Aというシステムで行った本人確認の結果を、信頼関係にあるBやCという別のサービスでも「よし、その結果を信じよう」と受け入れる構成を指します（ID連携とも呼ばれます）。
企業などでSaaSの導入数が増えると、社員1000人分のIDをサービスごとに作成・管理するのは現実的ではありません。そこで、「会社の中心となるシステムで一度だけ認証し、各SaaSはその認証結果を信頼して受け入れる」というフェデレーションの仕組みを使って、SSOという快適な体験を実現しているのです。
IdP(Identity Provider)とSP(Service Provider)：登場人物の役割
フェデレーション（ID連携）を実現するためには、明確な役割分担が必要です。ここで登場するのがIdPとSP（またはRP）という2つの主要なプレイヤーです。
IdP（Identity Provider）は、「IDの提供者」つまり認証を行う親元です。
ユーザー情報のデータベースを持ち、パスワードなどを検証して「この人は本人です」というお墨付き（認証トークンなど）を発行します。Google、Microsoft Entra ID（旧Azure AD）、Oktaなどが代表的なIdPです。
SP（Service Provider）は、IdPの認証結果を利用する「サービス提供者」です。
Salesforce、Slack、ZoomなどのSaaS側がこれに当たります。SPは自前でパスワード認証を行う代わりに、IdPが発行したお墨付きを受け取り、検証してユーザーをログインさせます。なお、OIDCの文脈ではRP（Relying Party）と呼ばれることもありますが、役割はほぼ同じです。
この関係性を理解すると、「IdPで障害が起きると、連携しているすべてのSPにログインできなくなる」といったリスク構造も見えてくるようになります。
OAuth 2.0 / OIDC / SAML の違いと使い分け：規格の整理
IdPとSPの間で「認証済みですよ」「権限を与えますよ」という情報をやり取りするためには、共通の言語（プロトコル）が必要です。それがOAuth 2.0、OIDC、SAMLです。
それぞれの特徴と違いを以下の表に整理しました。
| 規格名 | 主な役割 | データ・通信の形式 | 主な利用シーン |
|---|---|---|---|
| OAuth 2.0 | 認可（権限の委譲） | JSON（レスポンス） ※トークン形式は未規定 | API連携（「Googleフォトの写真を印刷アプリに渡す」など） |
| OIDC (OpenID Connect) | 認証 ＋ 認可 | JWT / JSON | スマホアプリやWebサービスの「Googleでログイン」など |
| SAML 2.0 | 認証 ＋ 認可 | XML | 企業の社内システムやSaaSへのSSO（業務利用が主流） |
SAML（サムル）は歴史が長く、XML形式を使うため少し重厚ですが、セキュリティ要件の厳しい企業間SSOで標準的に使われています。
一方、OIDC（オープンアイディーコネクト）は、OAuth 2.0の仕組みの上に「認証レイヤー」を追加した規格です。OIDCはOAuth 2.0に依存しており単独では動作しませんが、JSONベースで扱いやすく、モバイルアプリやモダンなWeb開発の現場では主流となっています。
OAuthとOIDCが混同される理由と解決策
ここまでの解説で一番ややこしいのが、「OAuth 2.0」と「OIDC」の関係です。
「OAuthでログイン機能を実装しました」と言うエンジニアがいますが、厳密にはOAuthは「認可（権限委譲）」のプロトコルであり、認証（本人確認）のためのものではありません。
OAuthの本来の使い方は、「家の合鍵（パスワード）は渡さないけれど、特定の部屋に入れるチケット（アクセストークン）だけ渡す」ようなものです。
なお、OAuth 2.0の仕様ではこの「チケット（アクセストークン）」の形式を定めていません（不透明な文字列の場合もあれば、JWTの場合もあります）。いずれにせよ、これだけでは「チケットを持っているのが誰か（ID情報）」までは保証されません。
そこで、OAuthの仕組みの上に「本人確認機能（IDトークン）」を乗せたのがOIDCです。
OIDCでは、認可のための「アクセストークン」に加え、身分証明書にあたる「IDトークン（JWT形式）」がセットで発行されます。これにより、アプリ側は「誰がログインしたか」を安全に知ることができるのです。
「API連携で機能を使わせたいだけならOAuth」、「ユーザーとしてログインさせたいならOIDC」と使い分けるのが基本です。
まとめ
ログイン周りの技術は、用語の「レイヤー」を意識することで整理できます。
- 行為：認証（本人確認）と認可（権限付与）は別物。
- 体験：SSOはユーザーにとってのメリット。
- 仕組み：フェデレーションで信頼関係を結ぶ。
- 役割：IdPが証明し、SPがそれを使う。
- ルール：SAMLは企業向け、OIDCはモダンなWeb/アプリ向け。
開発の現場やツールの選定において、「今、体験の話をしているのか？ 通信規格の話をしているのか？」を意識するだけで、コミュニケーションのズレは劇的に減ります。ぜひこの地図を頭の片隅に置いて、認証基盤の設計や運用に役立ててください。
