1 SSOの概要
1.1 SSOの基本概念
SSO（シングルサインオン）は、利用者が1回の認証で複数のサービスを追加ログインなし、または最小限の手間で利用できるようにする仕組みである。中心には認証基盤のIdP（Identity Provider）と、各サービス側のSP（Service Provider）があり、両者が連携することで認証済み状態を各所へ伝達する。
SSOの要点は、ユーザーの利便性だけではない。認証ポリシーをIdPに集約することで、サービスごとに個別実装していた認証判断を統一しやすくなり、運用負荷の低減や監査対応の一貫性にもつながる。
1.2 主要な登場人物（IdPとSP）
1.2.1 IdP（認証プロバイダ）の役割
IdPは利用者の認証を担い、認証結果を信頼できる形でSPへ提示する。具体的には、ユーザーの属性情報や認証の成立状況を、プロトコルに適合した形で送信し、SPがそれを根拠に利用者として扱うための前提を整える。
また、IdPは認証品質を規定する。例えば、多要素認証の要求、デバイスやリスクに応じた再認証、セッション有効期間の設定などがIdPの統制下に置かれるため、全体のセキュリティ水準を揃えやすい。
1.2.2 SP（サービスプロバイダ）の役割
SPは利用者が提供するサービス機能を利用できる状態にする責務を持つ。ユーザーがアクセスしてきた際に、SPはIdPへの認証要求を行い、戻ってきた情報を検証して認可判断に進む。SP側では、受領した主張（claims）や識別子に基づいて、アカウント対応付け、権限割当、セッション開始などを実装する。
さらにSPはログ出力やエラー処理、セッション失効の扱いなど、運用上の安定性にも寄与する。IdPから受け取った情報をそのまま信じるのではなく、署名検証や発行元の確認などの前提を満たすことが重要となる。
1.3 SSOが解決する課題
SSOが主に狙う課題は、認証作業の分散による不便と、認証運用の複雑化である。サービスが増えるほど、同一利用者が別々のログイン画面やパスワード管理に直面し、誤入力・再設定・利用停止などの問い合わせが増えやすい。
また、個別サービスで認証方針を実装する場合、MFA要求、パスワード更新方針、ブロック条件などの変更が発生するたびに影響範囲が広がる。SSOはこれらの判断をIdPへ寄せることで、方針変更の反映を一度で済ませる方向性を提供する。
1.4 SSOで変わるユーザー体験
ユーザー体験では、初回以外のログイン回数が大きく減る点が特徴である。ブラウザやアプリの利用範囲が広がるほど効果は顕在化し、同一の認証基盤に連携するサービス群を跨いだ移動が滑らかになる。
同時に、失敗時の見え方も変化する。あるサービスへのアクセスで認証要求が発生し、画面遷移や再確認が起こる場合がある。ユーザー視点では「一度済んだはずなのに追加の確認が出る」ケースがあり得るため、どの条件で再認証が必要になるかを前提として設計しておくことが重要である。
2 SSOの仕組み
2.1 認証とセッションの流れ
2.1.1 初回ログイン時のフロー
初回アクセスでは、対象SPは利用者を未認証と判断し、IdPへの誘導を開始する。通信は一般にブラウザのリダイレクトや、プロトコルに応じたリクエスト応答で進む。SPは「どのIdPとどのスコープで認証を求めるか」といった情報を用意し、ユーザーの認証画面へ遷移させる。
IdP側では利用者の認証を実施した後、認証結果をSPへ伝える。ここで生成されるのが、プロトコル固有のトークン、または主張を含むアサーションである。SPは戻ってきた情報の検証を行い、成立すれば自サービス内でのセッションを開始する。
2.1.1.1 セッション確立とトークン発行
セッション確立では、SPがユーザーの認証済み状態を保持する仕組みを構成する。一般に、ブラウザに格納するクッキーや、アプリ内のセッションストアなどが利用される。重要なのは、IdPで成立した認証結果と、SPが保持するセッションの有効範囲が同一でない可能性がある点である。
SPはIdPから得た情報を検証した上で、SPが扱える形のセッション指標を発行する。セッションの生存期間、更新の有無、端末やブラウザの状態に依存するかどうかなどは、サービス要件に合わせて定める。
2.1.2 2回目以降のアクセスフロー
2回目以降では、IdPのセッションが有効であれば、ユーザーは認証画面へ戻らずに済む。SPは自分のセッションが存在するかをまず確認し、未成立であればIdPへ問い合わせるが、その際にIdPが「既に認証済み」という状態を参照できると、追加手続きが省略される。
ただし、IdP側のセッション期限や再認証ポリシー、SP側のセッション期限が別々で設定されている場合、結果は一様ではない。SPのセッションが失効していても、IdPが有効なら短い往復で復帰できる一方、IdP側が失効していればユーザーは再ログインを求められる。
2.2 トークンとアサーションの考え方
トークンやアサーションは、認証結果や属性を、サービス間で機械的に扱える形に整形した情報である。形式や命名は技術方式によって異なるが、共通する役割は「検証可能な主張を提供し、SPが認可判断やセッション開始を行えるようにする」ことにある。
アサーションは署名などによって改ざん耐性を持たせ、SPが発行元や対象者、期限などを検証できるように設計される。トークンについても、用途に応じて種類が分かれ、誤った用途で使うと成立条件が満たせない場合があるため、仕様に沿った取り扱いが必要である。
2.3 リダイレクトとコールバック
多くの実装では、SPからIdPへの要求と、IdPからSPへの応答がリダイレクトとコールバックで成立する。SPがユーザーのブラウザをIdPへ送ると、IdPが認証後にユーザーをSPへ戻し、応答情報を指定されたエンドポイントへ届ける流れとなる。
コールバック設計では、受信側の検証が重要である。例えば、応答の整合性、対象のセッション開始要求との対応付け、遷移先URLの制約（許容範囲）などを満たさない場合、攻撃耐性や運用の安定性が損なわれる。リダイレクト先は設定の誤りが起きやすいため、テストと監視の両方が必要になる。
2.4 ログアウト（シングルログアウト）の考え方
2.4.1 ログアウトの範囲設計
ログアウトはSSOの効果を左右する重要領域である。シングルログアウト（SLO）は、IdP側のログアウトが連携先サービスにも反映されるようにする考え方を指すが、必ずしも全てのサービスで同等に達成されるとは限らない。
範囲設計では、どのセッションを終了対象とするかを定める必要がある。IdPのセッションのみを切る設計では、各SP側セッションは残る可能性があり、次アクセス時に再認証が発生することがある。逆に全SPで確実に終了させる設計では、複数連携の同期が必要になり、失敗時の扱いが複雑になる。
2.4.2 ログアウト失敗時の挙動
SLOは、複数のサービス間で順序や到達性が異なる状況を前提に設計する必要がある。あるSPでログアウト通知が届かなかった場合、ユーザー体験として「IdPはログアウトしたのに、特定のサービスだけまだ開ける」といった齟齬が生じ得る。
対策としては、失敗を許容する動作（例えばSP側セッションの短い有効期限、再アクセス時の追加検証）や、ログアウトイベントの監視、再試行方針などを組み合わせることが多い。どの程度の一貫性を目標とするかは、組織のセキュリティ要件とユーザー負荷のバランスで決める。
3 実装方式と技術要素
3.1 SAMLを用いたSSO
SAML（Security Assertion Markup Language）は、認証結果をアサーションとして受け渡す考え方が中心となる方式である。SPはIdPに対して認証要求を行い、IdPは署名されたアサーションを返送することで、SPはその内容を検証してセッション処理に進む。
SAMLは企業システムでの採用実績が多く、属性項目の扱い、メタデータによる構成管理などの枠組みが用意されている。実装では証明書管理や署名検証、時刻整合性、応答先の設定など、運用の細部が成否に直結しやすい。
3.2 OpenID Connectを用いたSSO
OpenID Connect（OIDC）は、OAuth 2.0の枠組みを背景に、認証（identity）を扱うためのプロトコルとして整理されている。IDトークンなどの形で認証に関する情報を表現し、SP（多くの場合はRP）がそれを検証することで認証を確定させる。
OIDCではフローが複数あり得るため、アプリ形態（サーバー型、SPA、モバイル）に応じて適切な方式を選ぶことが重要である。さらに、トークンの検証（署名、発行者、対象者、期限、nonceなど）と、通信の安全性確保が実装の中核になる。
3.3 認可（認可と認証の違い）
3.3.1 権限付与モデルの基本
認証は「誰か」を確かめる行為であり、認可は「その誰かに何を許すか」を決める行為である。SSO導入時は、IdPから受け取る情報を単なるログイン成立として扱うのではなく、サービス固有の権限モデルに結びつける必要がある。
典型的には、ロールや属性値に基づいてアクセス権を判定する。判定ロジックはSP側で管理され、組織内の業務要件や運用手順に合わせて定める。認可の基準をIdPへ寄せ過ぎると柔軟性が下がり、SP側へ寄せ過ぎると管理負荷が増えるため、責務分界を意識する。
3.3.2 ロールとスコープの設計
ロール設計では、権限の粒度と変更頻度を考慮する。細かすぎるロールは割当の管理が煩雑になり、粗すぎると過剰な権限付与につながる。スコープは、目的別に利用を制限する枠として扱われることが多く、トークンや要求に含めることで、取得できる情報や操作の範囲を絞る役割を担う。
設計段階では、最小権限の原則に従い、過去の手作業運用から置き換える項目を明確にする。さらに、付与変更が反映されるまでの時間や、反映漏れを検知する仕組みも合わせて決めることが運用安定につながる。
3.4 フェデレーション（連携関係）の構成
フェデレーションは、組織やシステム間で信頼関係を構築し、認証主張の相互利用を可能にする枠組みである。SSOが社内完結で行われる場合でも、複数テナント、複数部門、外部パートナーの取り扱いが出ると、信頼境界の設計が重要になる。
構成では、相互に信頼する証明書やメタデータ、識別子の対応付け、取り決めた属性の受け渡し仕様が必要になる。運用面では、加入・離脱、証明書ローテーション、障害時の切り戻しなどの手順も含めて整備することが望ましい。
4 導入設計と運用
4.1 対象サービスの棚卸し
導入計画では、連携対象となるサービスを洗い出し、認証方式、既存のユーザー管理、セッション方式、権限付与の仕組みを整理する。サービスごとにログイン画面の実装有無、API利用の有無、管理コンソールの扱いが異なるため、棚卸しは構成の基礎情報になる。
加えて、依存関係も確認する。例えば、同一ドメイン配下の複数アプリで統一的な挙動が期待される場合、ブラウザ制約やクッキー属性の違いが影響する。段階的導入では特に、切り替え影響の小さい領域から着手する判断材料となる。
4.2 IdP・SPの構成設計
構成設計では、IdPとSPの責務を明確にする。IdPは認証ポリシー、アカウント照合に必要な属性、トークン発行の前提となる設定を担う。SPは応答検証、セッション管理、サービス固有の権限解釈を担当する。
また、統合の単位も決める。単一IdPで全サービスを賄うのか、部門ごとに分割するのか、外部連携をどう扱うかで運用が変わる。設計段階では、将来のサービス追加に備えた設定の再利用性と、変更時の影響範囲を見積もることが重要である。
4.3 セキュリティ設計
4.3.1 多要素認証（MFA）連携
MFA連携では、IdP側での要求タイミングを定める。常時要求、リスク条件に応じた要求、特定操作時のみの要求など複数の方針が考えられる。SSOの利便性を維持しつつ、認証強度を確保する観点から、再認証が発生し得る状況を設計しておく必要がある。
SPはMFAそのものを実装するのではなく、IdPが提示する認証品質の情報を手掛かりに判断する場合が多い。結果として、認証の成立がどの条件で保証されたかを、サービスの監査目的にも反映できるようにする。
4.3.2 期限・更新・再認証の方針
セッションとトークンの有効期限は、利便性と安全性のバランスを作る。短すぎる期限は再ログイン回数を増やし、長すぎる期限は侵害時の影響を大きくする。加えて、端末単位の状態、ブラウザのクリア、ネットワーク経路の違いなども考慮する。
更新方針では、再発行の条件、失効時の挙動、期限切れをユーザーへどう伝えるかを定める。再認証の条件には、パスワード変更直後、疑わしい操作、権限が変化した場合などが含まれ得る。条件が複雑になるほど運用設計が難しくなるため、根拠と監査可能性を意識して絞り込む。
4.3.3 証明書・署名・検証の管理
証明書と署名の管理は、SSOの安全性の基盤である。IdPが発行する署名をSPが正しく検証できるように、公開鍵の配布、ローテーションのタイミング、メタデータ更新の手順を整える必要がある。
また、検証では発行者、対象、期限、リプレイ耐性のための要素などを確認する。実装誤りは直ちに重大インシデントにつながり得るため、設定変更の承認フロー、変更前後の検証、証跡の保持が欠かせない。
4.4 監査ログとトレーサビリティ
監査ログは、認証・認可の成立経路を追えることが目的である。どのIdPで、いつ、どの利用者が、どのサービスへ、どの結果で到達したかを関連づける設計が求められる。
トレーサビリティでは、相関IDやトランザクション識別子など、ログ同士を結び付けるためのキーを用意する。さらに、エラーイベントも監視対象とし、失敗原因の傾向分析に耐える粒度で記録することで、将来の改善につながる。
4.5 トラブルシューティング
4.5.1 よくあるエラーと原因切り分け
代表的な問題には、署名検証失敗、応答先不一致、期限切れ、属性不足、セッション不整合などがある。原因切り分けでは、まず設定差分（メタデータ、鍵、リダイレクト先、発行者の値）を確認し、その後にユーザー固有の状況（アカウント状態、属性割当、ポリシー適用）を調べる順序が有効である。
また、プロトコルのタイムアウトやネットワーク遅延によって発生する事象もあるため、ログに残る時刻情報とトレースを突き合わせる。再現性のない障害は、特定のブラウザや端末設定、キャッシュ挙動なども関与し得るため、環境差の確認が必要になる。
4.5.2 時刻ズレ・再送・セッション不整合の扱い
時刻ズレは検証条件に影響し、期限判定や署名有効範囲の検証でエラーを誘発し得る。NTP等での時刻同期を前提にしつつ、システム間で許容するズレ幅（許容時間）を設計で管理することが望ましい。
再送については、同じ応答が複数回処理されるとセッションが二重に作られる場合がある。対応としては、要求と応答の対応付けを厳密にし、同一トランザクションの再処理を抑止する。セッション不整合は、IdPの状態とSPの状態が異なることから起きるため、有効期限やログアウト方針との整合を取ることが対策になる。
4.6 移行（既存認証からの切替）
4.6.1 段階導入の進め方
段階導入では、影響範囲を抑えながら動作確認を行う。まずは限定ユーザーや少数サービスで試験し、認証の往復、属性の受け渡し、セッション維持、権限反映を観察する。次に対象サービスを広げ、管理コンソールや特権操作などの高リスク領域を優先度に応じて扱う。
また、切り替え時のロールバック経路を用意することが重要である。新方式に移行した後に重大な不具合が発覚した場合でも、短時間で元の認証へ戻せる手順を持つことで、業務停止リスクが下がる。
4.6.2 後方互換と切替計画
後方互換では、既存の認証経路とSSO経路を一定期間併存させる設計が用いられることがある。併存期間中は、ユーザー体験と管理負荷の両方を抑えるために、どの条件でSSOへ誘導するかを制御する。
切替計画では、移行対象の優先順位、通信・証明書の更新タイミング、検証環境と本番環境の差異、教育・周知の範囲を含めて工程化する。さらに、完了判定の基準（ログの整合、問い合わせ数、失敗率）を事前に定めることで、移行後の評価を客観化できる。