シングルサインオン（SSO）とは？仕組みと認証方式を解説

シングルサインオン（Single Sign-On：SSO）は、一度の認証を基に、複数のシステムを利用できるようにする仕組みです。例えば、社内のID基盤で認証した後、経費精算や社内ポータルで繰り返しパスワードを入力する負担を減らせます。

対象はSaaSだけではありません。オンプレミスや自社開発アプリ、クラウドサービスにも利用できます。本記事ではSAML 2.0とOpenID Connect 1.0を中心に解説します。参考資料と製品情報の確認日は2026年11月1日です。

SSOの目的とメリット

利用者はログイン操作や管理するパスワードを減らせます。管理者は、認証の方針やログをID基盤に集約しやすくなります。ただし、重要な操作やアクセス条件の変化によって再認証を求める場合があり、「一度ログインすれば永久に認証不要」という意味ではありません。

認証は「誰か」を確かめる処理、認可は「何をしてよいか」を決める処理です。SSOで本人が確認できても、その人に管理者操作を許可するかは別の判断です。

基本構成：IdPとSP

用語	役割	例
IdP（Identity Provider）	利用者を認証し、結果をアプリに伝える	組織の認証基盤
SP（Service Provider）	IdPの認証結果を検証し、サービスを提供	SAML対応の業務アプリ
OP（OpenID Provider）	OIDCで認証を提供	OIDC対応のID基盤
RP（Relying Party）	OIDCで認証結果を利用	Webアプリやモバイルアプリ

Microsoft Entra IDなどのクラウドID基盤をIdPとして利用する構成も、社内で運用するIdPを利用する構成もあります。アプリごとに信頼先と識別子、応答先URLなどを設定します。アプリは通常、IdPのパスワードそのものを受け取りません。

SAML 2.0とは

SAML（Security Assertion Markup Language）は、認証結果などをXMLで伝える標準です。SAML Assertionは、誰をいつどのように認証したか、どの属性を伝えるかなどを表します。署名と信頼設定を基に、SPが結果の正当性を検証します。

NameIDは利用者を表す識別子です。メールアドレス形式の場合もありますが、永続的な不透明IDなども使われます。表示名やメールアドレスと常に同じとは限りません。

SPから開始する認証フロー

利用者がSPにアクセスする。
SPがAuthnRequest（認証要求）を作り、ブラウザをIdPへ誘導する。
IdPが利用者を認証する。既存のIdPセッションを利用できる場合もある。
ブラウザを経由して、Assertionを含むSAML ResponseをSPのACS（Assertion Consumer Service：応答受信先）へ送る。
SPが署名、発行元、宛先、有効期限、要求との対応などを検証し、ユーザーを紐付けてアプリのセッションを作る。

これは代表的なWeb Browser SSOの例です。IdPから開始する方式もあるため、アプリの対応方式を確認します。署名が存在するだけで信頼せず、実績のあるライブラリで検証してください。

OpenID Connect（OIDC）とは

OIDCは、OAuth 2.0の上に認証の仕組みを定義した仕様です。OAuth 2.0は主にAPIなどへのアクセスを委任する認可のフレームワークであり、OAuthのアクセストークンを取得しただけで安全なログインが完成するわけではありません。

OIDCではID TokenというJWT形式のトークンを使い、認証結果と利用者を表すクレーム（情報項目）を伝えます。ユーザーの識別には通常、発行元のissと主体のsubの組を使います。ID Tokenはクライアント向けの認証情報であり、APIを呼ぶためのAccess Tokenとは用途が異なります。

Authorization Code Flowの例

RPがscope=openidを含む要求でブラウザをOPへ誘導する。応答先のredirect_uriを登録し、要求との対応にはstateなどを用いる。
OPが利用者を認証し、必要に応じて同意を取得する。
OPが登録された応答先へ短寿命の認可コードを返す。
RPがトークンエンドポイントでコードを交換する。PKCEを使用し、機密クライアントではクライアント認証も行う。
RPがID Tokenの署名、iss、aud、期限、送信した場合のnonceなどを検証し、アプリのセッションを作る。

PKCEは、認可要求を開始したクライアントとコードを交換するクライアントを結び付け、コードの横取りを悪用しにくくする仕組みです。上記は学習用の流れであり、実装時は最新のセキュリティ指針と利用するライブラリに従います。

SAMLとOIDCの比較

項目	SAML 2.0	OIDC 1.0
主な認証情報	XMLのAssertion	JWT形式のID Token
アプリ側の呼称	SP	RP、クライアント
利用者識別	NameIDや合意した属性	通常は`iss`と`sub`
代表的な場面	企業向けWebアプリのフェデレーション	Web・モバイルアプリのログイン
設定・検証の要点	メタデータ、証明書、ACS、Audience	Discovery、鍵、クライアント登録、redirect URI

どちらもSaaS専用ではありません。新旧だけで優劣を決めず、アプリの対応状況、ライブラリ、運用要件で選びます。

IDフェデレーションとの関係

IDフェデレーションは、異なるシステムや組織間で信頼を設定し、ID情報や認証結果を連携する考え方です。SAMLやOIDCによるフェデレーションはSSOの実現方法になります。一方、社内ドメインのKerberosなど、SSOには他の方式もあります。

クラウドID基盤、MFA、条件付きアクセス

Microsoft Entra IDなどを利用すると、アプリの認証を共通の基盤へ連携できます。MFA（多要素認証）は異なる種類の要素を組み合わせて本人確認を強化する仕組みです。SSOとMFAは目的が異なり、併用できます。

条件付きアクセスは、利用者、端末、場所などの条件に応じて認証やアクセスの要件を変える考え方です。Entra IDの具体的な機能・ライセンス要件は導入時に確認してください。利用先の全操作に同じ判断が毎回適用されるとは限りません。

認証手段の選択についてはパスキーの仕組み、端末や資源ごとの判断についてはNISTのゼロトラストアーキテクチャも参照してください。

セキュリティと運用上の注意点

確認事項	設計・検証すること
IdP障害	新規ログインへの影響、復旧連絡、業務継続手順。既存アプリセッションの挙動も確認
MFA・アクセス条件	管理者を含めて適用範囲を確認し、例外を記録
SSO以外のログイン	ローカルパスワード、別IdP、モバイル・API経由の経路を棚卸し
既存セッション	IdPとアプリのセッションは別。認証禁止やIdPログアウトだけで失効すると考えない
緊急管理者	通常の認証経路が使えない時の復旧手段を保護し、利用を監視・定期試験
証明書・鍵	期限、更新担当者、ローテーション時の切替手順を管理
識別子	改姓、メール変更、再雇用で別人への誤紐付けや重複が起きないか検証

SSOでログインを禁止しても、アプリ側アカウントや既存セッションが必ず削除・無効化されるわけではありません。シングルログアウトも、IdPとアプリ双方の対応や設定が必要で、あらゆるトークンの失効を保証するものではありません。

導入時の確認事項

まず対象アプリの対応規格、SSOの利用条件、識別子、既存アカウントとの対応を確認します。次に少数ユーザーで、正常なログインだけでなく、未割当ユーザーの拒否、MFA、メール変更、鍵更新、障害時の復旧を試します。最後に迂回経路と退職者のセッション処理を確認し、担当者と手順を文書化します。

アカウントプロビジョニングとの関係

初回ログイン時にユーザーを作るJITに対応するアプリもありますが、事前作成やログインしない人の更新・停止には別の仕組みが必要です。SSOとプロビジョニングの比較で役割を整理し、SCIMによるアカウント管理で導入方法を確認できます。

まとめ

SSOは認証を共通化する仕組みです。SAMLとOIDCの認証結果を適切に検証し、アカウント管理、権限管理、既存セッションの失効まで含めて運用を設計します。