シングルサインオン（SSO）とは？4つの実現方式と実装・IdP選定を開発視点で解説

シングルサインオン（SSO）とは、一度の認証で複数のサービスへログインできる仕組みのことです。利用者から見れば「パスワード入力が1回で済む」だけの機能ですが、実装する側から見ると、認証をどこに集約し、その結果をどうやって各サービスへ安全に受け渡し、セッションと失効をどう設計するかという、性質の異なる課題が重なります。この記事では、シングルサインオンとは何かという定義から、フェデレーション・代理認証・エージェント・リバースプロキシという4つの実現方式、SAMLのアサーション検証とOIDCのIDトークン検証の実装差、二重セッションとシングルログアウトの落とし穴、SCIMとJITによるアカウント連携、そしてIDaaSで組むか内製するかの判断軸までを、設計に落とせる粒度で整理します。

まとめ｜シングルサインオンの仕組みと導入判断の要点

シングルサインオンは、各サービスが個別に持っていた認証機能を1か所のIdP（Identity Provider・認証を担う側）へ寄せ、各サービス（SP・Service Provider）はIdPが発行した認証結果を検証して信頼する、という構造で成り立ちます。パスワードを複数サービスへ同じ値で配る「パスワード同期」とは別物で、SSOではSP側がパスワードを持たない点が本質的な違いです。

実装で押さえる軸は4つあります。1つ目は実現方式の選択で、SaaSや自社Webが相手ならSAML 2.0とOIDCによるフェデレーション方式が標準形になり、非対応の既存システムには代理認証・エージェント・リバースプロキシを当てます。2つ目は署名とトークンの検証で、SAMLならXML署名とアサーションの妥当性、OIDCならIDトークンの検証項目と鍵のローテーション追随が要点。3つ目がセッション設計で、IdPとSPが二重にセッションを持つため、ログアウトが全サービスに届かない問題を運用の前提として織り込みます。4つ目がアカウント連携で、退職者の権限をSP側から確実に消せるかどうかがSSOの価値を左右する点。判断の分岐点は「連携先がSSO標準に対応しているか」と「ID情報を握る主体が誰か」で、SaaS中心ならIDaaSの標準機能で組み切れる一方、自社サービスの会員基盤を自前で持つ場合は設計から固める価値が出ます。全体像から整理したい場合は認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を先に読むと位置づけが掴めます。

シングルサインオンとは｜IdPに認証を集約しSPが結果を信頼する構造

最初に言葉の定義と、混同されやすい仕組みとの違いを整理します。ここを曖昧にしたまま製品選定に入ると、要件と方式がずれたまま構築が進みます。

シングルサインオンの定義とパスワード同期・パスワード管理との違い

シングルサインオン（Single Sign-On・SSO）とは、利用者が1回認証を通せば、連携済みの複数サービスへ改めて資格情報を入力せずにアクセスできる仕組みを指します。核心は「認証の実行主体を1か所に集約する」ことにあり、各サービスは自分で本人確認をせず、集約先が出した認証結果を検証して受け入れます。

よく混同されるのがパスワード同期とパスワード管理ツールです。パスワード同期は複数システムへ同じパスワードを配って揃える運用、パスワード管理ツールは保管した資格情報を画面へ自動入力する仕組みで、どちらも各システム側の認証機能とパスワードはそのまま残ります。対してSSOでは連携先がパスワードを持たないため、退職時にIdPのアカウントを止めれば連携先すべてが同時に使えなくなる構造。この「止めれば全部止まる」という性質が、実装コストを払ってSSOにする最大の理由です。

認証と認可を分ける考え方とIdP・SP・アサーションの役割分担

SSOの設計では、認証（誰であるかの確認）と認可（何をしてよいかの決定）を分けて考えます。IdPが担うのは認証で、利用者のパスワードや多要素認証を検証し、その結果を署名付きのデータとして発行する役目です。SPは受け取った認証結果を検証して「確かにIdPが本人と認めた」と判断し、そこから先の権限判定は自分で行います。IdPが渡すのはあくまで本人性と属性であり、SP内部の細かい権限まではIdPが決めないのが原則的な役割分担です。

この受け渡されるデータを、SAMLではアサーション、OIDCではIDトークンと呼びます。いずれも署名が付いており、SPは署名の検証で内容の改ざんと発行元のなりすましを防ぐ仕組み。認証と認可の境界を整理したい場合はOAuth 2.0とは？仕組み・認可フローと認証・認可の違いを参照すると、SSOで扱う範囲がどこまでかを切り分けやすくなります。

SSOを実現する4方式｜フェデレーション・代理認証・エージェント・リバースプロキシ

SSOは単一の技術ではなく、連携先の性質に応じて実現方式を選びます。相手が標準プロトコルに対応しているかで、選べる方式が決まる構造です。

フェデレーション方式＝SAML・OIDCで認証結果を受け渡す標準形

フェデレーション方式は、IdPとSPが標準プロトコルで認証結果をやり取りする形で、現在のSSOの中心にある方式です。企業向けSaaSの多くはSAML 2.0に対応しており、OASISが2005年に標準化したXMLベースの仕様で、IdPが署名付きアサーションを発行しSPが検証します。一方のOpenID Connectは、OAuth 2.0の認可フローの上に本人確認の層を重ねた仕様で、openid.netが公開する原文ではCore 1.0が errata set 2 を取り込んだ版として2023年12月15日付で示されています（2026年7月時点）。

2つの使い分けは、連携先の対応状況で決まる部分が大きいのが実情です。既存の企業向けSaaS連携ではSAMLが求められる場面が多く、自社で新規にモバイルアプリやSPAを含む認証基盤を組むならOIDCのほうが実装しやすい傾向にあります。どちらも「IdPへリダイレクトして認証し、署名付きの結果を持ち帰る」という骨格は共通しており、片方を理解すればもう片方の理解も進む構造。プロトコル単位の詳細はSAMLとは？認証フロー・IdP/SPの仕組みとOIDC（OpenID Connect）とは？仕組み・OAuthとの違いで確認できます。なお社内ネットワーク限定であれば、Windowsドメインの統合Windows認証が使うKerberos（RFC 4120系）のチケットも、事実上のSSOとして機能します。

代理認証・エージェント・リバースプロキシ方式が向く既存システム

問題になるのは、SAMLにもOIDCにも対応していない既存システムです。ここで残り3方式が出てきます。代理認証方式は、利用者に代わってエージェントソフトやブラウザ拡張が保管済みの資格情報をログイン画面へ入力する方式です。対象システムを一切改修せずに済む反面、内部的にはパスワードが残るため「止めれば全部止まる」という利点は弱まります。

エージェント方式は、対象のWebサーバーへモジュールを常駐させ、それがSSOサーバーへ問い合わせて認証状態を判定します。対象サーバーへ手を入れられる社内システムで有効な一方、ミドルウェアのバージョンに依存するため、対象が増えるほど保守の負担が積み上がる方式。リバースプロキシ方式は対象システムの手前にプロキシを置いて通信経路上で認証を挟む構成で、アプリ側を改修できない場合に採れますが、全通信がプロキシを通るため性能と可用性の設計をプロキシ側で引き受けます。いずれも標準プロトコル対応への移行までの過渡的な選択と捉えておくと、判断を誤りません。

SAMLとOIDCの実装差｜アサーション検証とトークン検証の要点

フェデレーション方式を採ると決めたら、次はSP側の検証実装が焦点になります。SSOの事故の多くは、この検証の抜けから起きます。

SAMLの実装で外せない署名検証とIdP-Initiatedの注意点

SAMLのSP実装で最初に固めるのは、アサーションのXML署名検証です。IdPの公開鍵で署名を確かめ、宛先（Audience）が自分であること、有効期間内であること、同じアサーションを二度受け付けないことを、いずれも省かずに確認します。ここを自前で書くと踏みやすいのがXML Signature Wrapping、つまり署名が付いた要素と実際に読み取る要素をずらされる手口。署名検証は実績のあるライブラリやIdP製品側の実装に寄せるのが現実的な判断です。

もう1つの注意点がIdP-Initiated SSOです。SPからの要求に紐づかない形でアサーションが送り込まれるため、要求と応答を対応付ける検証が働かず、すり替えや再送の余地が生まれます。要件が許すならSP-Initiatedに寄せ、IdP-Initiatedを開ける場合は受信後の遷移先を限定するなどの補強が要ります。IdPの署名鍵そのものが漏れれば任意のアサーションを偽造できてしまう（いわゆるGolden SAML）ため、鍵の保護と定期的な入れ替えも設計に含める前提です。

OIDCの実装で確認するIDトークン検証とJWKSの鍵ローテーション

OIDCではIDトークン（JWT形式）の検証が中心になります。確認するのは、発行者（iss）が想定したIdPであること、宛先（aud）が自分のクライアントIDであること、有効期限（exp）が切れていないこと、認可要求時に渡したnonceが一致することです。nonceの照合を省くとトークンの使い回しを見抜けなくなるため、実装を急ぐ場面でも落とせない項目になります。

運用で効いてくるのがJWKS（JSON Web Key Set）の扱いです。IdPは署名鍵を定期的に入れ替えるため、SP側は鍵の一覧をキャッシュしつつ未知の鍵IDを見たら取り直す作りにしておきます。鍵一覧を起動時に一度だけ読んで固定する実装は、IdPの鍵交換のタイミングで全ログインが止まる典型的な事故に直結する構造。トークン検証の詳細はJWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いで確認できます。

SSOのセッション設計｜多重セッションとシングルログアウトの落とし穴

プロトコルの検証が正しく書けても、セッション設計を詰めていないとSSOは運用で崩れます。原因は、セッションが1つではなく複数存在する点にあります。

IdPとSPで二重に持つセッションの寿命と失効をどう設計するか

SSOでは、IdP側に「この利用者は認証済み」というセッションが立ち、各SP側にも「ログイン済み」というセッションが別々に立ちます。SPのセッションはSSO成立後は独立して生き続けるため、IdP側で状態が変わってもSP側は気づきません。結果として、IdPでアカウントを停止したのにSPのセッションが有効なまま残る、という状態が生じます。

設計では、SP側セッションの寿命をIdP側より短く取り、期限切れのたびにIdPへ確認を戻す形が基本になります。加えて、権限の変更や停止が即座に効いてほしい操作（決済、個人情報の閲覧、管理機能など）では、セッションに頼らずその都度IdPやディレクトリへ状態を問い合わせる設計にしてください。社内ディレクトリと連携する場合の仕組みはLDAPとは？ディレクトリサービスの仕組みとActive Directory・認証連携で整理できます。

シングルログアウトが機能しにくい理由と、現実的な失効設計の指針

「1回のログアウトで全サービスから抜ける」というシングルログアウトは、仕様としては存在します。SAMLにはSingle Logout（SLO）プロファイルがあり、OIDC側にも RP-Initiated Logout・Front-Channel Logout・Back-Channel Logout といった仕様が用意されている状況です（2026年7月時点）。それでも実運用で完全には効きません。理由は単純で、連携先のSPすべてが同じ仕様に対応していないと、対応していないSPのセッションだけが残るからです。サードパーティCookie制限が絡む方式では、通知そのものが届かない場合もあります。

現実的な指針は、シングルログアウトを唯一の失効手段にしないことです。退職や事故対応での即時遮断は、IdP側のアカウント停止とセッション取り消し、そしてSP側の短いセッション寿命という二段構えで担保します。そのうえで、対応しないSPは「セッション寿命が切れるまでは残る」という前提を運用ルールとして明文化しておく形が実務に合います。

SSOのアカウント連携｜SCIMプロビジョニングとJIT作成の使い分け

SSOはログインの仕組みですが、価値を出すのはアカウントのライフサイクル管理と組み合わせたときです。ここが抜けると、入社時の手作業と退職者アカウントの残存という元の課題が解けません。

SCIM 2.0による自動プロビジョニングと退職時アカウントの即時失効

SCIM（System for Cross-domain Identity Management）は、IdP側のID情報をSP側へ自動反映するための仕様で、RFC 7643がスキーマを、RFC 7644がプロトコルを定めています。IdPで入社処理をすれば連携先SaaSにアカウントが作られ、退職処理をすれば停止される、という連動をAPI経由で成立させる仕組み。SSOだけを入れた状態ではSP側にアカウントが残るため、SP側へ直接ログインする経路や発行済みのAPIトークンが生き残る余地が残ります。

そのため、退職時の即時失効を要件に掲げるなら、SSOとSCIMは組で導入すると考えたほうが設計を誤りません。連携先SaaSのSCIM対応は製品とプラン次第で差が出るため、対応範囲（作成・更新・停止・グループ同期のどこまでか）を選定段階で個別に確かめておきます。

JITプロビジョニングで足りる場面と、属性設計で詰まりやすい場面

SCIMに対応していないSPでは、JIT（Just-In-Time）プロビジョニングという選択肢があります。初回のSSOログイン時に、アサーションやIDトークンに載った属性を使ってSP側のアカウントをその場で作る方式で、事前の一括登録が不要になる利点。小規模な連携や、利用者が自分で使い始めるツールでは十分に回ります。

詰まりやすいのは属性設計と退職時の扱いです。JITは作成には効きますが停止や削除は原則として扱えないため、退職者アカウントはSP側に残ります。加えて、SP側が求める属性（メールアドレス、氏名、部署、ロール）の渡し方を決めておかないと、後からロール設計を変えたときに全連携先の属性マッピングを見直す羽目に。IdP側で「渡す属性の標準セット」を先に決め、SP追加のたびにその写像だけを定義する形にしておくと、連携先が増えても設計が破綻しません。

シングルサインオンを内製するかIDaaSで組むかの判断軸と外注が向く局面

ここからは判断を言い切ります。SSOは、連携先が標準プロトコルに対応した社内向けSaaS群であればIDaaSの標準機能で組み切れますが、自社サービスの会員基盤や既存システムが絡むと設計の巧拙が結果を分けます。

IDaaSの標準機能で組み切れるSSO要件と、採用してよい条件

次の条件に収まるなら、IDaaSを採用して標準機能で組むのが速く、保守も軽く済みます。連携先が主に企業向けSaaSで、いずれもSAMLかOIDCに対応していること。利用者が自社の従業員に限られ、権限設計がSP側の標準ロールで足りることです。この範囲であれば、署名検証も鍵のローテーションもSCIM連携もIDaaS側の機能で賄え、自社で書くコードはほぼ設定作業に収まります。

製品選定では、既存の社内ディレクトリとの相性、連携したいSaaSのコネクタの有無、多要素認証の方式が要件を満たすかを見ます。オープンソースで自社運用したい場合はKeycloakとは？メリット・デメリットとAuth0・Okta・Cognito比較が、商用IDaaSの機能と費用感を掴みたい場合はOkta（オクタ）とは？認証の仕組み・機能・料金・セキュリティが判断材料になります。適用イメージはGitHub SSOの設定手順｜SAML連携・PAT/SSH認可の落とし穴が具体的です。なおIdPの資格情報が奪われれば連携先すべてが同時に破られるため、多要素認証（MFA）とは？3つの認証要素と実装方式で扱う耐フィッシング性の高い方式との併用を前提条件に置いてください。

SSOの導入を見送る場面と、受託開発で設計を固めるべき認証要件

逆に、SSOを急いで入れないほうがよい場面もあります。連携したいシステムが1つか2つしかなく、いずれも標準プロトコルに非対応で代理認証しか採れない場合、パスワードが各システムに残るため「止めれば全部止まる」という本来の効果が出ません。この状態では、対象システムの標準対応やクラウド移行を先に検討したほうが投資が無駄になりません。IdPの冗長化と障害時の回避手段を用意できない体制も、導入を前倒しすべきではない条件です。

一方、次の要件が絡む場合は、初期の設計品質がその後の安全性と拡張性を決めるため、認証基盤の設計経験がある体制で固める価値が出ます。自社サービスの会員基盤にSSOを組み込み、外部IdPとの連携と自前の認証を併存させる構成。オンプレの基幹システムとクラウドをまたいでID情報を1つに束ねる構成。取引先や利用企業ごとにIdPを切り替えるマルチテナントの認証などです。これらはセッションと失効、属性設計、テナント分離が密に絡み、後から作り替えると全連携先の再設定を伴います。会員基盤と一体で認証を設計する開発は会員管理システムの受託開発で構想段階から相談でき、IDaaSの標準機能で走り出しつつ難所だけ外部の設計を挟む進め方も現実的です。

シングルサインオンでよくある質問｜仕組み・安全性・実装の疑問に回答

SSOの検討でよく挙がる質問に、仕組み・安全性・実装の観点から答えます。

シングルサインオンとパスワード管理ツールは何が違うのですか？

認証を行う場所が違います。パスワード管理ツールは、保管しておいた資格情報を各サービスのログイン画面へ自動入力する仕組みで、各サービス側の認証機能とパスワードはそのまま残ります。SSOでは連携先がパスワードを持たず、IdPが出した認証結果を検証して受け入れる構造です。この違いから、IdPのアカウントを停止すれば連携先すべてが同時に使えなくなります。

SSOはSAMLとOIDCのどちらを選べばよいですか？

連携先の対応状況で決まる部分が大きいのが実情です。既存の企業向けSaaSを束ねる用途ではSAML 2.0が求められる場面が多く、自社で新しく認証基盤を組むならOIDCのほうが実装しやすい傾向にあります。両方を扱えるIdPを選び、連携先ごとに使い分ける構成が無難です。

シングルサインオンのデメリットは何ですか？

最大の論点はIdPが単一障害点になることです。IdPが停止すれば連携先すべてにログインできなくなり、IdPの資格情報が奪われれば連携先すべてが同時に破られます。前者への備えはIdPの可用性設計と緊急時の代替経路、後者への備えは耐フィッシング性の高い多要素認証です。加えて、連携先が増えるほど属性とロールの写像を保守する手間が積み上がる点も、運用計画に織り込んでおく必要があります。

SSOを入れればログアウトも全サービスで同時に効きますか？

完全には効きません。SAMLのSingle LogoutやOIDCのログアウト関連仕様は存在しますが、連携先すべてが同じ仕様に対応していないと、対応していないサービスのセッションだけが残ります。実務では、シングルログアウトを唯一の手段にせず、IdP側でのアカウント停止とセッション取り消し、そしてSP側の短いセッション寿命を組み合わせて即時遮断を担保する設計にします。

SSOだけ導入すれば退職者のアカウントは消えますか？

消えません。SSOはログインの経路を止めるだけで、SP側のアカウント自体は残ります。SP側へ直接ログインする経路や発行済みのAPIトークンが生きていれば、アクセスが継続する余地も。退職時の確実な失効を要件にするなら、SCIM 2.0による自動プロビジョニングを組み合わせ、IdPの退職処理が連携先のアカウント停止まで届く形にしてください。

関連記事

• SAMLとは？認証フロー・IdP/SPの仕組みとOAuth・OIDCとの使い分けを実装視点で解説：SAMLの認証フローと署名検証を実装粒度で確認できます。
• OIDC（OpenID Connect）とは？仕組み・OAuthとの違いをわかりやすく解説：もう一方の標準プロトコルの仕組みとOAuth 2.0との関係を整理できます。
• JWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いを実装視点で解説：IDトークンに使うJWTの構造と検証項目を確認できます。
• 多要素認証（MFA）とは？3つの認証要素と実装方式・耐フィッシングMFAを実装視点で解説：SSOで併用が前提となる認証強化の方式を確認できます。
• 認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を解説【2026年版】：認証・ID管理の全体像と選定基準を判断軸から整理できます。