サイバーセキュリティ 
2020年11月、当時のデジタル改革担当大臣がPPA
社員が毎日10個も15個もクラウドサービスにログインしている。そんな状況に頭を抱え、シングルサインオン（SSO）の導入を検討し始めるIT担当者は少なくありません。しかし、SSOがどのような仕組みで動作しているのかを理解しないまま導入を進めると、期待した効果が得られないことがあります。
シングルサインオン（SSO）とは、1回の認証でIdP（IDプロバイダー）がトークンを発行し、複数のSP（サービスプロバイダ）へのアクセスを一括で許可する仕組みです。本記事では、IdPとSPの間で実際に何が行われているのかを5つのステップに分けて図解で解説し、SAMLトークンを使った認証の仕組みと主要な認証方式の全体像を、IT担当者向けにわかりやすく整理します。
シングルサインオン（SSO）とは
SSOとは「Single Sign-On（シングルサインオン）」の略で、ユーザーが一度ログインするだけで、連携している複数のシステムやクラウドサービスに認証なしでアクセスできるようにする仕組みです。
日本では、こうした認証の一元化は、もはや「あれば便利」ではなく、事実上の標準になりつつあります。改正個人情報保護法（APPI）の技術的安全管理措置では、個人データを扱う事業者に対して適切な認証の仕組みとアクセス制御の実装が求められています。さらに経済産業省の「サイバーセキュリティ経営ガイドライン Ver 3.0」では、ゼロトラストに基づく認証強化と、クラウドサービス利用にあたっての多層防御が、経営層が把握すべき重点項目として挙げられています。SSOは、こうした要求事項を企業規模で実装するうえで、最も整理された手段のひとつです。
本記事では、SSOが実際にどのような仕組みで動作しているのか、認証フローの内側に焦点を当てます。シングルサインオンのメリット・デメリットを慎重に検討する必要はあるものの、認証を一元化することは、ID管理を本気で考える企業にとって今や標準的な選択肢となっています。
SSOの認証の流れを図解で解説
SSOの認証は、5つのステップで実現されます。
SSOには、認証を担う「IdP（IDプロバイダー）」と、サービスを提供する「SP（サービスプロバイダ）」という2つの役割があります。IdPは、いわば会社の入館証を発行する受付のようなもの。SPは、その入館証で入れる各部屋やフロアです。ユーザーは受付（IdP）で一度本人確認を行うだけで、受付（IdP）で一度本人確認を行えば、許可されたすべての部屋（SP）にアクセスできる。それがSSOの基本的な考え方です。
各ステップの詳細を以下で解説します。
ステップ1：アクセス要求
ユーザーが業務で利用したいサービス（SP）にアクセスしようとします。例えば、SlackやSalesforce、kintoneといったクラウドサービスにブラウザでアクセスする場面を想像してください。
ステップ2：認証リクエスト転送
SPはユーザーがログイン済みかどうかを自分では判断できないため、認証基盤であるIdPに認証リクエストを転送します。ユーザーのブラウザは自動的にIdPの認証画面へリダイレクトされます。
ステップ3：認証（ID／パスワードの確認）
IdPの認証画面で、ユーザーがIDとパスワードを入力します。IdPは入力された認証情報を確認し、本人であることを検証します。多要素認証（MFA）が設定されていれば、この段階で追加の認証が行われます。
認証が成功すると、IdPはSAMLアサーション（認証済みの証明書）を発行します。SAMLアサーションには、ユーザーの識別情報、有効期限、そしてIdPによるデジタル署名が含まれています。
ここで重要なのは、ユーザーのパスワードはSPには一切送られないという点です。SPに渡されるのは署名済みのトークンのみであるため、通信が傍受されても、ID・パスワードそのものが漏洩しにくい設計になっています。これはトークンベース認証の大きなセキュリティ上の利点です。
ステップ4：SAMLアサーションの検証
SPは、IdPから受け取ったSAMLアサーションのデジタル署名を検証します。署名の検証に成功することで、SPは「このトークンが正規のIdPによって発行されたものである」と確認できます。
この仕組みのおかげで、SPはアクセスのたびにIdPに問い合わせる必要がなく、トークンの内容と署名だけでユーザーの認証状態を信頼できます。これがSSOの効率性とセキュリティを両立させている技術的な土台です。
ステップ5：アクセス許可・ログイン完了
検証が完了すると、SPはユーザーへのアクセスを許可します。ユーザーは追加のログイン操作なしで、目的のサービスを利用できるようになります。
そして以降、同じIdPが発行したトークンが有効である間は、他の連携済みSPへのアクセスでも再ログインは不要です。1回の認証で、許可されたすべてのサービスにシームレスにアクセスできる。これがSSOの基本動作です。
仕組みを通じて実現されること
このように、ユーザーが意識しないところで、IdPとSPの間ではトークンの発行と検証が自動的に繰り返されています。ユーザーから見れば「1回ログインすれば、あとは何もしなくても各サービスが使える」というシームレスな体験ですが、その裏側では安全なトークンベース認証が常に動いています。
そしてパスワードをSPに直接渡さない設計こそが、SSOがもたらすセキュリティ上の最大の強みです。利便性とセキュリティを両立する仕組みとして、SSOが多くの企業で導入されている理由がここにあります。
SSOの認証方式の全体像
SSOには、いくつかの代表的な認証方式があり、どれが自社に合うかは「どこにシステムがあるか」で大きく変わります。クラウドSaaS中心で運用している企業なら、現代のクラウドサービスが標準で対応している「フェデレーション方式（SAML / OIDC）」が自然な選択肢になります。一方、オンプレミス中心の環境では、社内のディレクトリと相性のよい「エージェント方式」や「Kerberos / LDAP」が選ばれることが多くなります。SAMLに対応していない古いアプリにもSSOを広げたい場合は、「代理認証方式」や「リバースプロキシ方式」を使えば、アプリ自体に手を入れずに対応することが可能です。各方式の特徴は、以下の表で並べて確認できます。
| 認証方式 | 主な対応環境 | 導入率 | 特徴 |
|---|---|---|---|
| フェデレーション方式（SAML 2.0 / OIDC） | クラウドSaaS全般 | 最も高い | 主要クラウドサービスの標準。Okta、Microsoft Entra ID、Google Workspaceと標準連携 |
| エージェント方式 | オンプレ・社内システム | 中 | プロキシ経由で認証処理を行う。アプリ側の改修が不要 |
| リバースプロキシ方式 | Webアプリ全般 | 中 | プロキシ経由で認証処理を行う。アプリ側の改修が不要 |
| 代理認証方式 | フォーム認証アプリ | 低め | SSO非対応アプリのID/PWを、エージェントが代行入力する |
| Kerberos / LDAP | 社内ネットワーク | 大企業中心 | Windowsドメイン環境で広く利用。オンプレの標準的な方式 |
SSOの理解の先に、Keeperで完成させるIDセキュリティ
ここまでSSOの仕組みを見てきて、SSOには得意な領域とそうでない領域があることが見えてきたと思います。SSOは「社員のログインを1回にまとめる」という点では非常に強力な仕組みですが、その恩恵を受けられるのは、SAMLやOIDCといった現代的なログイン規格に対応しているアプリだけです。もし社内でこれらに対応していないアプリを使っている場合、社員はそのアプリ用に別途アカウントを作り、別途パスワードを覚える必要が出てきます。SSOを導入しても、こうしたアプリの認証はSSOではカバーできない、というのが実情です。
実際の業務現場には、SAMLに対応していない古い社内システム、共有が必要なサービスアカウント、認証方式を現代化していない取引先ポータル、開発者がローカルで使うAPIキーなどの、SSOではカバーしきれない認証情報が必ず存在します。こうした認証情報も、どこかで安全に管理する必要があります。SSOを導入したのに、結局これらを社員の記憶や付箋に頼っていては、ID管理の本質的な目的は果たせません。
ここでKeeperが活きてきます。KeeperはSAML 2.0に対応したすべてのIdPと連携できるため、社員がSSOで認証した瞬間に、SSOでは届かないすべての認証情報を管理するボルトへのアクセスも開かれます。さらに、開発現場で扱うAPIキー、データベース認証情報、CI/CDトークンといった「コードやパイプラインに埋め込まれがちな機密情報」については、Keeper シークレットマネージャーがソースコードからの分離と安全なローテーションを担います。Keeper SSO コネクトと組み合わせることで、ID管理の全体像が完成します。新しいクラウド環境はフェデレーション認証で、日常的な認証情報はゼロ知識暗号化されたボルトで、開発者の機密情報はSecrets Managerで、それぞれ最適に管理される。これにより、エンドユーザーの体験はひとつのフローのまま、組織全体のID管理が抜け漏れなくカバーされます。
最も成功するSSO展開は「SSOだけでは全範囲をカバーできない」という前提から始まっています。SSOとパスワードマネージャーを最初から同じID戦略に組み込んでおくことが、導入から半年後にプロジェクトが頓挫する原因となる「認証情報の散逸」を防ぐ最も確実な方法です。SSOでは届かない認証情報をKeeperでどう管理できるかは、ビジネス向け無料トライアルで実際に試せます。組織規模に応じた価格を確認したい場合は、お見積りを依頼ください。
よくある質問
SSOはどのような仕組みで実現されていますか？
IdPがユーザーを認証してトークンを発行し、各SPがそのトークンを検証することでアクセスを許可する仕組みです。ユーザーは1回ログインするだけで、連携する複数のSPに再ログインなしでアクセスできます。詳しくは本記事の「SSOの認証フローを図解で解説」の章をご覧ください。
SAMLとシングルサインオンはどのような関係ですか？
SAMLは、SSOを実現するための代表的な標準プロトコルの一つです。SSO自体は「1回の認証で複数サービスにアクセスする」という仕組みの総称であり、その実装方法としてSAMLやOpenID Connect、Kerberosなど複数の方式があります。SAMLはエンタープライズ向けクラウドサービス連携の事実上の標準として広く使われています。
SSOの仕組みがまったくわからない初心者でも理解できますか？
はい。SSOは「1本のマスターキーで会社の複数の部屋に入れる仕組み」とイメージすると理解しやすいです。マスターキーを発行する受付の役割を担うのがIdP、そのキーで入れる各部屋がSPに相当します。一度受付で本人確認をすれば、許可された部屋へは何度でも自由に出入りできる。それがSSOの基本的な考え方です。
クッキーを使ったSSOでは、なぜ異なるドメイン間で認証できないのですか？
ブラウザのCookieは、セキュリティ上の理由から発行元のドメインを越えて共有することができない仕様だからです。そのため、複数の異なるドメインのサービスをSSOで連携させる場合は、Cookieではなく、SAMLやOpenID Connectといった、ドメインをまたいで認証情報を安全に受け渡せる標準プロトコルが必要になります。これが、フェデレーション方式が現代のクラウドSSOで主流になっている理由でもあります。
