SSO（シングルサインオン）の基礎 ─ IdP・SP・SAML・OAuth・OIDCを整理する

SSO（シングルサインオン）の基礎

概要

この記事は、SSO（シングルサインオン）の基礎知識を個人学習用にまとめたものです。学習の進捗に合わせて内容を追記していく、書きかけの記事です。

本記事では、複数のサービスに一度の認証でログインできる仕組みである**SSO（Single Sign-On：シングルサインオン）**の基礎を整理する。

社内システムやSaaSの利用が増えた現在、SSOはID・アクセス管理（IAM / IDaaS）の中核をなす技術である。その裏側では、SAML や OAuth 2.0 / OpenID Connect といった標準プロトコルが使われており、それぞれ「認証（Authentication）」と「認可（Authorization）」のどちらを担うのかを正しく区別して理解することが重要になる。

本記事では以下の問いに答えられるようになることを目標とする。

• SSOとは何で、何がうれしいのか（パスワード管理・セキュリティ・運用の観点）
• 登場人物である IdP（Identity Provider） と SP（Service Provider） の役割
• 「認証」と「認可」の違い
• 代表的なプロトコル（SAML / OAuth 2.0 / OpenID Connect）の位置づけと使い分け

SSOとは何か

定義

SSO（Single Sign-On：シングルサインオン） とは、一度の認証で、連携した複数のサービスに再ログインなしでアクセスできる仕組みである。

カギは、認証を IdP（後述）という1箇所に集約し、各サービスには「このユーザーは認証済み」という証明だけを渡す点にある。ユーザーが各サービスへパスワードを配るわけではない。

SSO ≠ パスワードの使い回し
同じパスワードを各サービスに登録するのは、認証情報が分散したままで、1つ漏れれば芋づる式に破られる。SSOはその逆で、認証情報を1箇所にまとめ、各サービスには「認証済みの事実」だけを渡す。

仕組み（イメージ）

ユーザーはIdPで1回だけ認証し、各サービスはIdPの「認証済み」の証明を信頼してログインを通す。

何がうれしいのか

SSOがない世界では、サービスが増えるほどID・パスワードの管理が破綻していく。SSOは認証をIdPへ一元化することで、これをまとめて解決する。

SSOがない場合の課題	SSOによる改善
サービスごとにID・パスワードを管理	1回のログインで複数サービスへ（利便性↑）
覚えきれず使い回し・弱いパスワードに	認証がIdPに集約され、使い回しが減る
MFA等のポリシーを各サービスで個別設定	IdPにMFAを1回設定すれば全サービスに適用
パスワードリセット対応でヘルプデスク負荷	管理の一元化で運用・監査が楽になる
退職時にサービスごとに無効化（漏れやすい）	IdP側でアカウントを停止し、新規ログインを一括制御

MFA（多要素認証）とは
パスワード（知識）に加え、スマホのワンタイムコード（所持）や指紋（生体）など別種の要素を組み合わせる認証方式。1つ漏れても突破されにくい。

注意点（トレードオフ）

便利さの裏返しで、「認証を1箇所に集める」ことに由来するリスクもある。

• 単一障害点（SPOF）: IdPが止まると、連携する全サービスにログインできなくなる
• 侵害時の影響が大きい: IdPが破られると被害が全サービスに波及する。だからIdPでのMFAが前提
• 導入・運用の複雑さ: SAML / OIDC などの連携設計が必要になる

SSOは認証を集約するがゆえに、その1点の防御（MFA）と可用性がより重要になる。メリットとこのトレードオフはセットで語れるようにしておきたい。

認証と認可の違い

SSOを正しく理解するうえで欠かせないのが、認証と認可の区別である。名前が似ていて混同しやすいが、担う役割はまったく違う。

定義

• 認証（Authentication / AuthN） ＝「あなたは誰か」を確かめる（本人確認）
• 認可（Authorization / AuthZ） ＝「あなたに何を許すか」を決める（権限付与）

順序は必ず 認証 → 認可。まず誰かを確かめ、その上で何を許すかを判断する。

	認証（AuthN）	認可（AuthZ）
問い	あなたは誰か？	何をしてよいか？
役割	本人確認	権限の付与・制御
例	ログインする	管理者だけ削除できる
順序	先に行う	認証の後に行う

身近な例（空港）

• 認証：パスポートで「本人か」を確認する
• 認可：搭乗券で「この便に乗ってよいか」を確認する

本人確認（認証）が済んでも、乗れる便（認可）はまた別の話、という関係。

SSOの文脈での認証・認可

SSOが一元化するのは、主に 認証（本人確認）である。IdPが本人確認を一手に引き受ける。

一方「何をしてよいか（認可）」は各サービス側の判断だが、その際にIdPから受け取る属性（所属グループ・ロールなど）を使って権限を決めることも多い。認証と認可は、SSOの中で連携して働く。

よくある混同：OAuth 2.0は「認可」の仕組み
OAuth 2.0は認可のプロトコルであり、そのままでは「認証」には使えない。「誰がログインしたか」を知りたいときは、OAuth 2.0を拡張した OIDC（OpenID Connect） を使う。詳しくは後のセクションで扱う。

この「認証」を担うのが IdP、認証結果を信頼してサービス提供と認可を行うのが SP である。次章で両者の役割を詳しく見る。

登場人物：IdPとSP

SSOは、IdP と SP という2つの登場人物の役割分担で成り立っている。

それぞれの役割

• IdP（Identity Provider） ＝ 認証する側。ユーザーの本人確認を行い、「認証済み」の証明を発行する。ID情報を一元管理する。
• SP（Service Provider） ＝ サービスを提供する側。自分では認証せず、IdPの認証結果を信頼してログインを通す。

	IdP	SP
役割	認証する側	サービスを提供する側
すること	本人確認し、証明を発行する	IdPの証明を信頼してログインを許可する
認証情報	持つ（一元管理）	持たない（IdPに委ねる）
例	Google、Microsoft Entra ID、Okta、GMOトラストログイン	Slack、Salesforce などの各種SaaS

基本の流れ

ユーザーがSPにアクセスしてからログインが通るまでの、おおまかな流れは次のとおり。

両者の信頼関係（トラスト）

SPは、見知らぬIdPの「認証済み」を勝手に信じてはならない。もし信じてしまえば、偽のIdPがなりすまし放題になるからだ。そこで両者は事前に信頼関係（トラスト）を結んでおく。

• 事前準備：IdPとSPがメタデータや鍵（証明書）を交換し、「このSPはこのIdPを信頼する」と設定しておく
• 証明の署名：IdPは発行する証明に電子署名する（IdPの秘密鍵）
• 署名の検証：SPはIdPの公開鍵で署名を検証し、改ざんや偽造でないことを確かめる

秘密鍵と公開鍵（電子署名のしくみ）
ペアで使う2つの鍵で、ここで使うのはどちらもIdPの鍵。IdPの秘密鍵はIdPだけが持ち署名に使い、IdPの公開鍵はSPに配っておき検証に使う（同じペアなので対応する）。

• IdPの秘密鍵で署名 → IdPの公開鍵で検証（署名と検証は必ず同じペア）
• 署名はIdPの秘密鍵を持つIdPにしか作れないので、なりすましを防げる
• ※SP自身の鍵は、IdPの署名検証には使わない

この「事前の信頼関係」と「署名検証」があるからこそ、SPはIdPの証明を安全に信頼できる。

信頼関係を結ぶ具体的な手順はプロトコルによって異なる（SAMLはメタデータ交換、OIDCはクライアント登録など）。詳細は各プロトコルのセクションで扱う。

ここまでで登場人物と大枠がそろった。次は、この仕組みをどういう方式で実現するかの分類を見ていく。

SSOの実現方式の分類

SSOを実現する方法は1つではない。中心となるのはフェデレーション方式だが、それに対応していないサービスのために別の方式も使われる。代表的な方式を整理する。

主な方式

方式	しくみ	長所	短所
フェデレーション方式 （SAML / OIDC）	標準プロトコルで「認証済み」の証明をやり取りする。パスワードはSPに渡さない	安全・標準的。SaaSや組織をまたいで連携できる（今の主流）	サービス側がSAML/OIDCに対応している必要がある
代理認証方式 （フォームベース）	SSO製品がID・パスワードを預かり、各サービスのログイン画面に自動入力する	SAML/OIDC非対応の古いサービスにも使える	パスワードを預かる・保管するリスクがある
リバースプロキシ方式	ユーザーとサービスの間にプロキシを挟み、そこで認証を集約する	サービス側の改修が少なくて済む	プロキシが通信経路の要（SPOF・ボトルネック）になりうる
エージェント方式	各サーバーに専用エージェント（ソフト）を入れ、認証を代行・IdPと連携する	サーバー単位できめ細かく制御できる	各サーバーにエージェントの導入・運用が必要

フェデレーション（federation）とは
「連携」の意味。組織やサービスをまたいで、パスワードそのものは渡さず「認証済み」という結果だけを信頼し合うしくみ。SAML と OIDC がその代表。

これまで説明してきたモデル＝実はフェデレーション方式
前のセクションで見た「IdPが署名付きの証明を発行し、SPが公開鍵で検証する」「パスワードをSPに渡さない」というモデルは、実はこのフェデレーション方式そのものである。
一方、代理認証など他の方式は、SSO製品がパスワードを預かって代理入力するなど、別の仕組みで実現する（むしろ「パスワードを渡さない」の逆）。

どれを使う？

• 今の主流は フェデレーション方式（SAML / OIDC）。SaaS連携の事実上の標準で、パスワードをSPに渡さないため安全。
• ただしSAML/OIDCに対応していない古いサービスもある。そのためIDaaS製品は、代理認証方式なども合わせて用意し、対応できるサービスの幅を広げていることが多い。

ここまではSSOの全体像だった。次からは、主流であるフェデレーション方式の中身——SAML、OAuth 2.0、OIDC——を1つずつ見ていく。

SAML

SAMLとは

SAML（Security Assertion Markup Language） は、XMLベースのフェデレーション認証の標準規格。IdPとSPの間で「認証済み」「この人はこういう属性を持つ」という情報を、XMLの文書でやり取りする。現在広く使われているのは SAML 2.0（2005年〜）で、企業向けSSOの定番として長く使われてきた。

SAMLアサーション（中身）

SAMLの主役が アサーション（Assertion）。IdPが発行する「この人は認証済みです」という証明書のようなXML文書で、IdPの秘密鍵で署名されている（SPがIdPの公開鍵で検証する）。

主に次の情報が入る。

• 誰か：ユーザーの識別子（メールアドレスなど）
• 認証済みという事実：いつ・どの方法で認証したか
• 属性：所属グループ・ロールなど（SP側の認可に使える）
• 有効期限：いつまで有効か

2つのログインフロー

SAMLには、ログインの開始地点の違いで2パターンある。

• SPイニシエート（SP-initiated）：ユーザーが**SP（サービス）**からアクセスを始める。最も一般的
• IdPイニシエート（IdP-initiated）：ユーザーがIdPのポータル（アプリ一覧画面など）から始め、アプリを選ぶ

もっとも一般的なSPイニシエートの流れは次のとおり。

アサーションはブラウザ経由で運ばれる
④⑤のように、アサーションはIdPからSPへ直接ではなく、ユーザーのブラウザを経由して渡される（HTMLフォームの自動送信などを使う）。SPがアサーションを受け取る窓口を ACS（Assertion Consumer Service） と呼ぶ。
IdPイニシエートの場合は①②が不要で、IdPがいきなり④のアサーションをSPへ送るところから始まる。

ユースケースと立ち位置

• 企業のSaaS SSOの定番。Google Workspace、Salesforce、AWS、Slack など多くのSaaSがSAML連携に対応している
• 一方、XMLで重く・ブラウザ前提のため、モバイルアプリやSPA・API向けには後発の OIDC が好まれる傾向。両者の使い分けはOIDCのセクションで扱う

OAuth 2.0

OAuth 2.0とは（認可の仕組み）

OAuth 2.0 は、あるアプリに対して「このユーザーのデータへの限定的なアクセス」を、パスワードを渡さずに許可するための認可の標準規格（RFC 6749、2012年）。

具体例で考えるとわかりやすい。ある写真印刷サービスに、Googleフォトの写真を取り込ませたいとする。このとき、

• Googleのパスワードを印刷サービスに教える → 危険（全データを渡すのと同じ）
• OAuth 2.0を使う → 印刷サービスに「Googleフォトの読み取りだけ」を許可し、パスワードは渡さない

これがOAuthのやりたいこと、「アクセス権限の限定的な委譲」である。

OAuth 2.0は「認可」であって「認証」ではない
OAuthが与えるのは「このリソースにアクセスしてよい」という許可であって、「誰がログインしたか」を証明する仕組みではない。この一線が、次のOIDCを理解する鍵になる。

4つの登場人物

登場人物	役割	例（写真印刷サービスの場合）
リソースオーナー	データの持ち主（＝ユーザー）	あなた
クライアント	アクセスを求めるアプリ	写真印刷サービス
認可サーバー	本人確認・同意を取り、アクセストークンを発行する	Googleの認可サーバー
リソースサーバー	保護されたデータを持ち、トークンと引き換えに渡す	Googleフォト

認可コードフロー

最も標準的な流れが認可コードフロー。ポイントは、「認可コード」をいったん受け取り、それを「アクセストークン」に交換するという2段階になっていること。

なぜ2段階（コード → トークン）なのか
④⑤の認可コードはブラウザ経由で渡るが、短命で使い捨て。しかもトークンに交換するには⑥でクライアント認証情報（アプリが事前登録でもらう合言葉＝client_secret。ユーザーのパスワードとは別物）が必要なため、コードを盗まれても単体では悪用しにくい。
肝心のアクセストークンは⑥⑦のサーバー間通信（裏側）でのみ受け渡すので、ブラウザのURLなどに露出しない。この2段階が安全性の要になっている。
なお、SPAやモバイルアプリのように client_secret を安全に保持できないクライアントでは、代わりに PKCE（Proof Key for Code Exchange）という仕組みで認可コードの不正利用を防ぐ。

そして「認証」には足りない

OAuth 2.0はあくまで「このアプリにこのリソースへのアクセスを許す」＝認可の仕組みだった。アクセストークンは「アクセスを許された証」であって、「この人が確かに本人だと確認した証」ではない。

そのため、OAuth 2.0だけで「ログイン（認証）」を組もうとすると危うい。この足りない「認証」の部分を、OAuth 2.0の上に標準化して乗せたのが、次に見る OIDC（OpenID Connect） である。

OpenID Connect（OIDC）

OIDCとは（OAuthに「認証」を乗せる）

前章のとおり、OAuth 2.0は認可の仕組みで、「誰がログインしたか」を扱えなかった。この足りない認証の層を、OAuth 2.0の上に標準化して乗せたのが OIDC（OpenID Connect）（2014年、OpenID Foundation）。

仕組みはOAuthの認可コードフローとほぼ同じ。違いは次の2点だけ。

• クライアントが openid スコープを要求する
• 認可サーバーが、アクセストークンに加えて IDトークン（後述）を返す

図にすると、OAuthの認可コードフローとの違いは ⑦でIDトークンが返る点だけだと分かる。

「⑧でIDトークンを検証して誰がログインしたかを知る」ところが、認可だけだったOAuthに認証が加わった部分である。

なお、SAML・OAuth・OIDCでは同じ役者でも呼び名が変わる（いなくなるわけではない）。混乱したらこの対応表に戻るとよい。

何者か	SAML	OAuth 2.0	OIDC
ユーザーが使うアプリ／サービス	SP	クライアント	RP
認証・トークン発行を担う側	IdP	認可サーバー	OP

特にOIDCのOPは、OAuthの「認可サーバー」と、認証を行う「IdP」の役割を兼ねる。だからOAuthの図にあった認可サーバーは消えたのではなく、OPに統合されている。

IDトークン（JWT）

OIDCの主役が IDトークン。「この人が確かに認証された」ことを証明する、OP（IdP）発行の署名付きトークンである。

• 形式は JWT（JSON Web Token）：JSONベースのコンパクトなトークン（ヘッダ.ペイロード.署名 の3部構成）
• OPの秘密鍵で署名され、RPがOPの公開鍵で検証する（署名の考え方はSAMLアサーションと同じ）
• 中身（クレーム）の例：

クレーム	意味
iss	発行者（どのOPが出したか）
sub	ユーザーの一意なID
aud	宛先（どのRP向けか）
exp	有効期限
name / email 等	要求したスコープに応じたプロフィール情報

ここで、OAuth章で保留した2つのトークンの違いがはっきりする。

	IDトークン	アクセストークン
目的	認証（誰がログインしたか）	認可（リソースにアクセスしてよいか）
使う相手	RP自身が中身を読む	リソースサーバーに提示する
中身	ユーザーの情報（クレーム）	アクセスの許可証（RPは中身を気にしない）

SAMLとの比較・使い分け

SAMLとOIDCは、どちらもフェデレーションでSSOを実現するプロトコルだが、世代と得意分野が違う。

	SAML	OIDC
形式	XML	JSON / JWT
登場	2005年	2014年
土台	独自仕様	OAuth 2.0の上に構築
得意分野	企業向けSaaS・社内システム	モバイル・SPA・API、ソーシャルログイン

• 新規のWeb/モバイル/API連携なら、軽量でOAuthと親和性の高い OIDC が主流
• 既存の企業向けSaaSでは SAML が依然として広く使われている

「Googleでログイン」「Appleでサインイン」などのソーシャルログインは、OIDCで実現されている身近な例。

これでSSOを支える主要プロトコル（SAML / OAuth 2.0 / OIDC）が揃った。最後に、これらを束ねて実際のサービスとして提供する IDaaS を見ていく。

実サービスにおけるSSO（IDaaS）

IDaaSとは

IDaaS（Identity as a Service） とは、ID管理・認証をクラウドで提供するサービスのこと。

これまで見てきた IdP／フェデレーション／SAML・OIDC を、自前で構築・運用する代わりに、サービスとして手軽に使えるようにしたものと言える。実質的に、IDaaSが「IdP」の役割を担う。

IDaaSが提供する主な機能

IDaaSはSSOを核としつつ、ID管理に関わる機能をまとめて提供することが多い。

機能	内容
SSO	SAML / OIDC で各SaaSと連携し、一度のログインで複数サービスへ
多要素認証（MFA）	ログインに追加の要素を要求し、なりすましを防ぐ
プロビジョニング	アカウントの作成・更新・削除を自動化（SCIM という標準を使う）
アクセス制御	IP・デバイス・場所などの条件でアクセス可否を判断する
監査ログ	誰がいつログインしたかを記録し、レポートする

プロビジョニングとSCIM
入社・退職などに合わせて、各SaaSのアカウントを自動で作成・削除する仕組みをプロビジョニングと呼ぶ。これを標準化したのが SCIM（System for Cross-domain Identity Management）。SSO（ログインの一元化）と組み合わせることで、アカウントのライフサイクル全体を一元管理できる。

代表的なIDaaS

• 海外：Okta、Microsoft Entra ID、Google Workspace、Auth0、OneLogin など
• 国内：HENNGE One、CloudGate UNO、LOCKED、GMOトラストログイン など

各サービスの対応プロトコルや個別機能（料金・上限・対応SaaSなど）は変化しやすいため、正確な仕様は必ず公式ドキュメントで確認すること。本記事では「IDaaSというカテゴリの位置づけ」を示すに留める。

なぜIDaaSを使うのか

• 導入が手軽：自前でIdPを構築・運用しなくても、SSO基盤を短期間で導入できる
• セキュリティ運用を任せられる：MFAや不正アクセス対策など、専門的な運用をサービス側に委ねられる
• 管理の一元化：SSO＋プロビジョニング＋アクセス制御＋監査を1箇所でまとめて管理できる

まとめ

本記事では、SSOの基礎を次の流れで整理した。

1. SSOとは何か：一度の認証で複数サービスへ。利便性とセキュリティを上げるが、認証を集約するトレードオフ（SPOF・侵害時の影響）も伴う
2. 認証と認可：「誰か（認証）」と「何を許すか（認可）」は別物
3. IdPとSP：認証する側と、それを信頼する側。両者は署名・検証によるトラストで結ばれる
4. 実現方式：主流はフェデレーション方式（パスワードを渡さず「認証済み」の結果だけを信頼し合う）
5. プロトコル：SAML（XML・企業向けの定番）、OAuth 2.0（認可）、OIDC（OAuthに認証を乗せたもの）
6. IDaaS：これらを束ねてクラウドで提供する実サービス

「SSO」という一見シンプルな仕組みの裏側で、認証と認可の区別・トラスト・プロトコルの使い分けが働いていることが、全体像として見えてきたはずだ。