SSO

概要

SSO（シングルサインオン）は、一度のログインで複数のサービスを利用できるようにする仕組みです。朝一番に会社のポータルにログインすれば、メール・チャット・勤怠・クラウドストレージへは再度パスワードを入力せずに入れる — 企業で働く人が毎日体験しているこの動きが SSO です。各サービスが個別にパスワードを預かって認証する代わりに、認証を専門に担う一箇所（IdP、Identity Provider）に集約し、各サービスはその結果を信頼する、という構造の転換がその中身です。

SSO は特定のプロトコル名ではなく「一度のログインを使い回す」という設計思想・体験の名前で、実現手段として SAML や OIDC といった標準プロトコルが使われます。Google アカウントひとつで Gmail・YouTube・ドライブに入れるのもコンシューマ向けの SSO ですし、社給アカウントで数十の SaaS に入れるのはエンタープライズ SSO です。

利便性の仕組みに見えますが、本質はむしろセキュリティと管理の仕組みです。認証が一箇所に集まることで、MFA（多要素認証）の強制やアクセスポリシーの適用、退職者のアカウント停止が、その一箇所を押さえるだけで全サービスに行き渡ります。

なぜ生まれたか

SSO 以前、サービスが増えるたびにアカウントとパスワードも増えていきました。利用者は数十のパスワードを覚えきれず、使い回しや付箋メモに走ります。1つのサービスから漏れたパスワードが他のすべてを危険にさらし、パスワードの使い回しは攻撃者にとって最も効率のよい侵入口になりました。管理者側の負担も深刻で、社員1人の入社のたびに数十サービスへアカウントを作成し、退職のたびにすべてを消して回る必要があります。1つでも消し忘れれば、退職者が社内データにアクセスできる穴が残ります。ヘルプデスク業務の相当な割合が「パスワードを忘れました」対応で占められる、という状況も常態化していました。

この「認証がサービスの数だけ分散している」構造そのものを解くのが SSO です。認証を IdP に一元化すれば、利用者が覚えるパスワードは1つになり、管理者はアカウントの発行・停止・ポリシー適用を一箇所で完結できます。2000年代前半に SAML が企業間の認証連携を標準化し、クラウドサービスの爆発的な増加（1社で使う SaaS が数十〜数百という時代）が、SSO を「あれば便利」から「ないと管理不能」の必須基盤へと押し上げました。

詳細

登場人物と信頼関係

SSO の登場人物は3者です。ユーザー、認証を担う IdP、そしてユーザーが実際に使いたいサービスである SP（Service Provider）です。前提として、IdP と各 SP のあいだには事前に信頼関係を結んでおきます — 具体的には署名検証用の証明書やクライアント情報を交換し、「この IdP が発行した認証結果なら受け入れる」と SP 側に設定しておきます。この事前の信頼設定があるからこそ、SP はパスワードを一切預からずにユーザーを受け入れられます。

SP-initiated フロー — ブックマークから始まる SSO

実際の流れとして最も一般的なのが、ユーザーが SP 側から使い始める「SP-initiated」フローです。ポイントは、認証が必要になった SP がユーザーのブラウザを IdP へ「リダイレクトで送り出し」、IdP が認証結果を持たせて「送り返す」という往復にあります。

初回は IdP のログイン画面が表示されますが、このとき IdP はブラウザとの間に Cookie ベースの「SSO セッション」を確立します。2つ目以降のサービスにアクセスすると、同じくリダイレクトで IdP に到着しますが、SSO セッションが生きているためログイン画面は表示されず、即座に認証結果が返ります。ユーザーから見ると「一瞬画面が切り替わっただけでログインできた」ように見える — これが「一度のログインで複数サービス」の正体です。逆に IdP 側のポータル画面からアプリ一覧をクリックして始める形は「IdP-initiated」フローと呼ばれます。

セッションの二層構造

SSO を理解する鍵は、セッションが二層になっていることです。IdP とブラウザの間の「SSO セッション」と、各 SP とブラウザの間の「アプリケーションセッション」は別物で、寿命も独立に管理されます。SP は認証結果を受け取った後は自前のセッションで動くため、IdP からログアウトしても既存の SP セッションは即座には切れません。全サービスから一斉にログアウトする「シングルログアウト」は、各プロトコルに仕様はあるものの実装が難しく、実務では「SP セッションを短命にして IdP へ頻繁に再確認させる」形で近似することが多い、というのが現実的な落としどころです。退職者対応でも「IdP のアカウント停止＝即座に全 SP から締め出し」とはならない点は、設計時に意識すべき典型的な注意点です。

プロトコルと周辺概念

認証結果の受け渡しに使う標準が、XML ベースの SAML と、OAuth 2.0 の上に認証を載せた OIDC です。エンタープライズの SaaS 連携では SAML が長年の実績を持ち、新規構築やモバイル・API を含む構成では OIDC が選ばれる傾向にあります。Okta・Microsoft Entra ID・Google Workspace・Keycloak といった IdP 製品は両方に対応しており、SP 側の対応状況に合わせて使い分けるのが実情です。SSO と混同されやすいものに、認証後の「何をしてよいか」を決める認可がありますが、SSO が担うのはあくまで認証までで、権限管理は RBAC など各サービス側の仕組みと組み合わせます。また、アカウントの作成・削除を自動同期するプロビジョニング（SCIM）も、SSO とセットで導入されることの多い隣接概念です。

設計上のトレードオフ

認証の一元化は「単一障害点の一元化」でもあります。IdP が落ちれば全サービスにログインできなくなり、IdP のアカウントが乗っ取られれば全サービスが芋づる式に危険にさらされます。だからこそ IdP には MFA の強制・リスクベース認証・厳重な監視といった最高水準の防御を集中させる、というのが SSO 設計の基本姿勢です。守るべき場所を一箇所に絞って徹底的に固める — この考え方は、アクセスのたびに検証を求めるゼロトラストアーキテクチャにおいても、IdP を中核に据える形で受け継がれています。