シングルサインオン（SSO）とは？
仕組みや認証方式をわかりやすく解説

SAML認証

「SAML認証」は、異なるドメイン間でのユーザー認証を行うために定められました。Google WorkspaceやMicrosoft 365など、多くのクラウドサービスがSAMLに対応していることから、特に利用されることが多い認証方式です。後で紹介する「HENNGE One」というSaaS認証サービスも、このSAML認証を採用しています。

SAMLの基本的な仕組みは、IDプロバイダ（IdP）とサービスプロバイダ（SP）の2者間で認証データをやりとりすることです。ユーザーがWebサイトにアクセスしようとすると、SPは認証リクエスト（SAML）をIdPに送信します。

IdPはこのリクエストを受けてユーザーに認証操作を要求し、その結果をまたSPに返して、ログインを許可してよいかどうかを伝えます。すでにユーザーが認証操作に成功していた場合、IdPはそのときの情報をそのままSPに送信するので、ユーザーは何度も認証操作を繰り返す必要がありません。

SAMLの詳細については、以下の記事も参考にしてください。

エージェント方式

Webサーバーやアプリケーションサーバーにエージェント（代理人）となるソフトウェアを導入する方式です。エージェントは外部のSSOサーバーと連携し、Cookieを使ってログイン情報を管理します。

初回ログイン時、ユーザーはSSOサーバーの要求に対して認証操作をしなければなりません。SSOサーバーはその認証結果をエージェントに送り、エージェントがさらにその情報をSSO対象のWebサーバーに送信します。2度目のログイン以降は、Webサーバーに保存されたCookieを使ってログインの許可をします。

エージェント方式はネットワーク構成に手を入れる必要がない代わりに、WebサーバーがSSOに対応していないと使えないのがネックです。

代行認証方式

代行認証方式とは、クライアント端末に導入されたエージェントが、ユーザーの代わりにログイン画面へID/パスワードを入力する方式です。代理認証方式と呼ばれることもあります。エージェントはユーザーがログイン画面を開いたのを感知すると、あらかじめ設定されているID/パスワードを自動で打ち込みます。

エージェントが行っているのは、入力画面にID/パスワードを打ち込むことだけなので、代行認証方式の仕組みは単純で、Webサービスに対して大幅に手を加える必要がありません。

そのため、改修が難しい古いアプリケーションなども含めて対応できるサービスが多く、比較的容易に導入できる点が魅力です。

リバースプロキシ方式

Webサービスと認証サーバーの間にリバースプロキシと呼ばれる中継サーバーを設置し、そこへ導入したエージェントに認証を行わせて各サービスにログインする方式です。

個々のWebサーバーではなく、中継サーバーにエージェントを置くことで、エージェントの導入が難しいサービスにも対応できる強みがあります。

ただし、この方式ではシングルサインオンに対応したサービスへアクセスしようとする全てのトラフィックが、リバースプロキシサーバーを経由します。

そのため、負荷がかかってボトルネックになりやすい点に注意が必要です。また、トラフィックがリバースプロキシを経由するようにネットワーク設計を調整する必要もあります。

透過型方式

透過型方式はユーザーによるサービスへのアクセスを監視するサーバーを配置しておき、必要時のみ認証情報を送信する方式です。

1. ユーザーがサービスにアクセス
2. 監視サーバーがユーザーの認証情報を認証サーバーに要求
3. 監視サーバーが認証情報を受け取り、サービスへのアクセスを許可

2の認証情報には有効期限があり、期限が切れると再度認証サーバーに要求する仕組みです。有効期限内であれば、ユーザーは他のサービスに認証なしでアクセスできます。

各サービスに透過型方式が可能な監視サーバーを配置できれば、透過型方式のSSOを実現可能です。ネットワークへの負荷が小さく、ブラウザや環境（クラウドかオンプレミスか）などの制約もないため、メリットが多いSSO方式といえます。

ケルベロス方式

ケルベロス方式はケルベロス認証によってSSOを実現する方式です。ケルベロス認証は以下の仕組みで実施されます。

1. ユーザーがサービスにアクセスし、IDやパスワードを用いてログイン
2. 認証サーバー（AS）がログインしたユーザーを認証し、チケット（TGT）を発行
3. ユーザーは2で受け取ったチケット（TGT）を用いて、利用したいサービスにアクセスをリクエスト
4. リクエストを受けたサービスの認証サーバー（TGS）がチケット（TGT）を確認し、サービスチケット（≠TGT）を発行
5. ユーザーがサービスチケットを用いてサービスにアクセス

TGTには有効期限が設けられており、有効期限内であれば、3,4,5の処理のみで他のサービスにもアクセスできます。TGTの有効期限後は1からやり直しです。

ただしユーザーはTGTやサービスチケットを意識した操作は必要ありません。1の操作以外はクレデンシャル情報を扱うことなく、SSOが実現します。

利便性の向上

社内システムやWebサービスを利用する際、それぞれに認証を求められるのは大変な手間です。また、複数のログイン用パスワードを使用していると、管理も煩雑になります。

その点、シングルサインオンを活用すれば、1回のログインで全てのWebサービスにアクセスできます。ログインのたびに作業の手を止める必要がなくなる点は、大きなメリットです。

ただし、利用しているWebサービスが必ずしもシングルサインオンに対応しているとは限らないため、その点は留意しておいてください。

セキュリティリスクの軽減

パスワードを管理するのが面倒で、複数のWebサービスで同一のパスワードを使いまわしたり、手元のメモや付箋にパスワードを記録したりしている方も多いのではないでしょうか。そうでなくとも、覚えやすいように単純なパスワードを設定しているかもしれません。

当然、これらの管理体制は、セキュリティ面で大きな問題を抱えています。パスワードを使いまわしていると、1つのWebサービスのログイン情報が流出しただけで、全てのWebサービスが危険にさらされます。また、メモや付箋による管理も、物理的な紛失・盗難リスクがあり、安全とは到底いえません。単純なパスワードの構成に至っては、不正アクセスの対象となった際、簡単に推測・突破されてしまうでしょう。

こうした問題は、シングルサインオンを利用することで解決します。シングルサインオンでは、管理すべきID/パスワードは、すべてのWebサービスを合わせて1つです。1つだけなら管理は難しくないでしょうし、記憶することもそこまで苦ではありません。

管理負担の軽減

複数のパスワードを従業員が管理していると、パスワード忘れやアカウントロックが起こることもあるでしょう。そうした場合、IT部門や情報システム部門に所属するシステム管理者が、通常の業務を中断してフォローにあたらなければなりません。

シングルサインオンの導入によりID/パスワードが1組になれば、従業員が自分で管理できるようになるので、管理者の負担が軽減されます。会社によっては、人員配置の見直しなどによって、コスト削減につながることもあるでしょう。

ID統合と比較すると低コスト

SSOシステムはID統合基盤サービスと比較すると低コストなメリットがあります。

ID統合基盤サービスはSSOの機能と、ID管理の機能を提供するサービスです。ID管理の機能はシステムにログインするためのユーザーIDやパスワード、および組織情報を管理します。ID統合基盤サービスはSSOとID管理が統合されているため、管理負担の低減が可能です。また認証サーバーに対する頻繁なアクセス要求を防ぐことになるため、セキュリティリスクの低減も実現します。

しかし、ID統合基盤サービスはSSOよりも高機能なため、コストが高くなりやすいです。よってSSOの機能だけで十分だと考える企業には、SSOの方がコストパフォーマンスが高いメリットがあります。

パスワード流出によるリスク

シングルサインオンで使用しているID/パスワードが流出してしまうと、連携している全てのWebサービスへの不正アクセスを許すことになります。

この点を懸念して、導入に踏み切れずにいる方も多いことでしょう。しかし、このリスクに関しては、後述の多要素認証などと組み合わせることで対策が可能です。

システム停止によるリスク

シングルサインオンそのもののシステムが停止してしまうと、全てのWebサービスにログインができなくなってしまいます。緊急時に備えて、経営に関わる重要なシステム・Webサービスのログイン情報は別途管理するなど、対策を講じておきましょう。

導入コスト

シングルサインオンの導入方法は、自社サーバーにソフトウェアをインストールする「オンプレミス型」と、クラウドサービスを利用する「クラウド型」に分かれます。

特にオンプレミス型は買い切りのため、初期費用が高額な傾向にあります。また、クラウド型についても、「ユーザーあたり月額○○円」という形式をとっていることがほとんどです。そのため、従業員数が多かったり、利用期間が長くなったりすると、費用はかさみます。

多要素認証

多要素認証は、シングルサインオンと同時に活用したいセキュリティの代表例です。これは、ID/パスワード以外にも、生体情報や所持情報などの要素も認証時に要求する仕組みを指します。

生体情報の例としては指紋や顔、所持情報の例としてはスマホや磁気カードなどが挙げられます。例えば、認証時にスマホへSMSなどで送信されるワンタイムパスワードの入力も必要とすることで、万が一ID/パスワードが漏えいした際にも不正アクセスを避けられます。

多要素認証は、認証時に追加の手間がかかってしまうことが欠点です。

しかし、一回の認証操作で複数サービスのログインを実現できるシングルサインオンと組み合わせることで、そのデメリットを最小限に抑えられます。このように、多要素認証とシングルサインオンは互いの欠点を補える好相性の関係です。

IPアドレス制限

IPアドレス制限も、認証セキュリティを高めるための効果的な手法として挙げられます。IPアドレスとは、どこからどの端末がネットワークにアクセスしているのかを示すインターネット上の住所のようなものです。

IPアドレス制限をすることで、自社のオフィスや支給端末からアクセスしているユーザーだけに認証許可を出すことが可能になります。もしも悪意ある第三者がID/パスワードを入手したとしても、IPアドレスが異なれば認証されなくなるので、安全性を高めることが可能です。

コンテキストアウェアセキュリティ

IPアドレス制限にも関係しますが、コンテキストアウェアセキュリティの導入も有効な手法です。これは、IPアドレスやデバイス、アクセスしようとしている場所や時間など、複合的な文脈に照らしてアクセス制御をする方法を指します。

例えば、就業時間外にいつもと違う場所からアクセスしようとしているユーザーがいたとしたら、システムがそれを不審だと検知してアクセス制限をかけます。あるいは、カフェや駅の公衆無線LANなど、セキュリティ的に問題のある方法でアクセスしようとしているユーザーに制限をかけるなども、組織のセキュリティポリシーを守るために有効な方法の1つです。

自社の課題を解決できるか

SSOシステムを選ぶ際に最も重要なポイントは自社の課題を解決できることです。

SSOシステムに求めることは、ユーザーの高い利便性と企業のセキュリティ強化です。それぞれのニーズがあるのに、どちらかがおざなりになってしまうと自社の課題解決はできません。

例としてセキュリティ強化は実現するが、従業員が使いたいサービスにはほとんど対応していないSSOシステムを導入したケースを考えます。

このケースでは従業員はシステムを使わずに従来の方法でログインするでしょう。結果としてセキュリティ強化も実現できず、導入自体が無駄になってしまいます。

ユーザー、企業それぞれの課題を解決できるSSOシステムを選ぶことが必要になります。

SSO以外のセキュリティ機能は十分か

SSOシステムを選ぶ際にSSO以外のセキュリティ機能が十分かどうかを確認しましょう。

SSOはセキュリティ対策の一種です。しかし、シングルサインオン（SSO）のデメリットでも述べたように、SSO自体のデメリットへの対策ができていないと、かえって利便性が失われたり、セキュリティの問題が大きくなったりします。特にSSOは一つのサービスのアクセス情報が盗まれてしまうと、それ以外のサービスにもアクセスできてしまうため、被害が大きくなりやすいです。

よって多要素認証や、コンテキストウェアなどSSOを狙った攻撃を防ぐ対策ができるSSOシステムを導入しましょう。

費用対効果は十分か

SSOシステムを選ぶ際に費用対効果が十分にあることもポイントです。

SSOをすることによって得られるメリットと、導入に必要なコストを比較しましょう。また導入の際にはシステムの準備や習熟など別のコストも発生します。トータルのコストとメリットを比較した上で「それでも必要だ」と判断した場合にSSOシステムを導入すべきです。

逆にメリットよりもコストが上回る場合には別の方法での実現や、選定のやり直しを検討しましょう。