「OAuthで認証してます」
「SSOってSAMLのこと？」
「OIDCってOAuthの上位互換？」
このあたり、言葉の形が似ていて普通に混ざります。
で、混ざったままでも開発は進んでしまうので、なおさら厄介です。
ただ、ここで詰まる原因は「専門用語が多いから」じゃなくて、もっと単純で、種類の違う言葉が同じレイヤーに置かれがち だからだと思っています。
- 体験の名前（SSO）
- 信頼のつなぎ方（フェデレーション）
- 登場人物の役割（IdP / SP）
- 受け渡しのルール（OAuth / OIDC / SAML）
レイヤーを分ければ、用語が多くても意外と迷子になりません。この記事はそのための整理です。
TL;TD
- 認証（AuthN）：あなたは誰？
- 認可（AuthZ）：あなたは何ができる？
- SSO：1回ログインで複数サービスを使える「体験」
- フェデレーション：別システムの認証結果を「信頼して受け取る」仕組み
- IdP：本人確認して「認証済み」を発行する側
- SP/RP：それを受け取って検証し、サービスを提供する側
- Auth 2.0：権限を委譲する（認可）
- OIDC：OAuth 2.0 の上に「認証（ID Token）」を追加
- SAML 2.0：企業SSOでよく見る、認証結果をアサーションで渡す方式
まずは“困りごと”から：社員1000人の現実
会社に社員が1000人いるとして、サービスを増やすたびにそのサービス用のユーザーを作る世界を想像してみてください。
- SaaSを導入するたびにユーザー1000人作成
- 退職した人の削除が漏れる
- 異動した人の権限が追いつかない
- 誰がどこに入れるか棚卸しが終わらない
- パスワードが増えて、どこかで事故る
たぶん「運用のしんどさ」が最初に限界を迎えます。
だから現実的には、方針がこう変わります。
- 本人確認は“会社の中心”で一回
- 各サービスは その結果を信頼して受け取る
- できればユーザーは「一回ログイン」で済ませたい
この要求を言葉にすると、SSOやフェデレーションの話になっていきます。
全体像：どの棚に置く言葉か（地図）
いきなり細かい話に入ると混ざるので、先に位置関係だけ置きます。
ここで重要なのは、「SSO・フェデレーション・SAML/OIDC」が横並びじゃないことです。
- SSOは「ユーザーの体験名」（一回ログインで済むと嬉しい）
- フェデレーションは「信頼でつなぐ仕組み」（Aの認証結果をBが受け入れる）
- SAML / OIDCは「その受け渡しをするための規格」
- OAuth 2.0は別棚で「認可（権限委譲）」の話。OIDCはその上に認証を足す
「SSO = SAML」みたいに言い切るとズレるのは、SSOが“体験の名前”で、SAMLが“規格（ルール）”だからです。
より正確には「SSOを実現するためにSAMLを使うことがある」です。
認証（誰？）と認可（何していい？）
Auth周りが噛み合わないとき、だいたいここが混ざっています。
- 認証（Authentication / AuthN）：あなたは誰？
- 認可（Authorization / AuthZ）：あなたは何ができる？
ホテルでたとえるとシンプルです。
チェックインで本人確認（認証）
↓
部屋キーで入れる範囲が決まる（認可）
Webでも似た話がよく起きます。
- 401：あなた誰？（認証が必要/失敗）
- 403：あなたは分かったけど、それはダメ（認可で拒否）
「ログインできるのに403が出る」のは、認証は成功していて、権限が足りないだけ…というケースが本当に多いです。
SSOは“体験”, フェデレーションは“信頼の仕組み”
SSOはユーザー目線です。
- 朝イチでポータルにログインしたら
- 以降、勤怠もメールも社内Wikiも、追加ログインなしで使える
「便利だな」という感覚がSSOです。
一方、フェデレーションはシステム目線です。
- 会社の認証基盤が「この人は田中さん」と認証する
- 勤怠システムがその結果を信頼してログインさせる
- メールも同じ
- 社内Wikiも同じ
つまりフェデレーションは「Aが認証した結果を、Bが受け入れる」という信頼の仕組みです。
SSOという体験を支える土台として、フェデレーションがよく登場します。
ここでありがちな勘違いがひとつあります。
- フェデレーションは“誰か”ではなく、“仕組み”
- その仕組みの中に登場人物（役割）がいる
次で、その登場人物をはっきりさせます。
IdPとSP/RP：フェデレーションの登場人物（役割）
フェデレーションを現実の構成に落とすと、だいたい登場人物はこの2つです。
- IdP（Identity Provider）：認証する側。ログイン元。本人確認して「認証済み」を発行する
- SP（Service Provider）/ RP（Relying Party）：サービス提供側。IdPの結果を受け取り、検証してログインを成立させる
図にするとこうです。
認証する側（IdP） サービス提供側（SP/RP）
+-------------------+ 認証結果を渡す +------------------------+
| IdP | -----------------> | SP / RP |
| 本人確認する | | 受け取って検証して |
| 「認証済み」を発行 | | サービスを提供する |
+-------------------+ +------------------------+
^
|
ユーザーはIdPでログインする
ここが「フェデレーションの中身ってIdP？」という疑問につながりやすいところですが、関係はこうです。
- フェデレーション：Aの認証結果をBが受け入れる “仕組み全体”
- IdP：その中の「認証して結果を出す役割」
- SP/RP：その結果を受け取って利用させる役割
そして SAMLやOIDCは、IdP→SP/RPに“認証済み”を渡すためのルールです。
「誰が何を渡すか」がわかると、用語が急に安定します。
OAuth 2.0：パスワードを渡さず、権限だけ渡す（認可の話）
ここまでの話は「ログイン（認証）」寄りでした。
OAuth 2.0 は棚が違って、主役はログインではなく 権限の委譲です。
たとえばこういうやつ。
- 写真プリントのアプリが「あなたの写真」を読み取りたい
- でもアプリにGoogleのID/PWを渡すのは嫌
- 「写真の読み取りだけOK」みたいに範囲を絞って許可したい
このときに出てくるのがOAuth 2.0です。
流れを“体感”で追うとこうなります（最後にユーザーへ結果が返るところまで描きます）。
OAuth 2.0 がやっているのは、ざっくり言うとこれです。
- ID/PWを渡さない
- 代わりに「この範囲だけOK」な通行証（Access Token）を渡す
だから「OAuthで認証してます」と言うと、文脈によってはズレます。OAuthの中心はあくまで“許可（認可）”です。
OIDC：OAuth 2.0 に「あなたは誰か」を足す（ログインっぽくなる理由）
OAuth 2.0 の世界だけだと、「このトークンで写真APIを読める」は表現できます。
でもアプリ側はだいたいこう言い出します。
- 「この人をユーザーとして登録したい」
- 「ログイン状態を作りたい」
- 「メールアドレスやユーザーIDがほしい」
ここで OIDC が出てきます。OIDCはOAuth 2.0 の仕組みを使いつつ、認証の結果（あなたは誰か） を扱えるようにしたものです。
そのために出てくるのが ID Token です。
混ざりやすいので、トークンは用途で切ると楽です。
Access Token : APIに行くための通行証（権限）
ID Token : "あなたは誰か" の身分証（ユーザー情報）
Refresh Token : Access Tokenを更新する鍵
OIDCが「認証 + 認可」に見えるのは、現場では Access Token も一緒に扱うことが多いからです。
ただ、OIDCが“追加している本体”は「認証（ID Token）」の側だと押さえておくと、混線しにくくなります。
SAML 2.0：企業SSOでよく見る“認証結果の受け渡し”
SAMLは企業SSOでよく見かけます。
構造は意外と素直で、IdPが認証して、その結果をSPに渡す、という形です。
OIDCとSAMLは世界観が違って見えるかもしれませんが、骨格は似ています。
- IdPが認証する
- SP/RPが受け取り検証する
- ログインが成立する
違いは「何をどう渡すか」というルール（規格）の部分です。
まとめ
Auth周りがややこしく感じるのは、単語の暗記が足りないからというより、違う種類の言葉が同じレイヤーに置かれがちだからだと思っています。
- 認証（誰？）と認可（何していい？）を分ける
- SSOは体験、フェデレーションは信頼の仕組み
- フェデレーションの登場人物が IdP と SP/RP
- OAuth 2.0 は認可（委譲）
- OIDCはOAuthの上に認証（ID Token）を足す
- SAMLは企業SSOでよく見る認証連携
このレイヤー分けができると、会話の中で「今どのレイヤーの話？」が掴みやすくなって、仕様も実装も追いやすくなります。