はじめに

上司やお客様から突然「シングルサインオン(SSO)を検討して」と言われた場合、どうしますか？
いずれ弊社（オープンソース・ソリューション・テクノロジ株式会社）のような専門ベンダに連絡するとしても、
その前に、ベースの知識を得ておくためにWeb上で情報を探してみるのではないでしょうか。

シングルサインオン(SSO)という分野は、アプリ開発の分野に比べると関わっている人が
少ないということもあり、初めての人向けの纏まった＆最新化された情報というのは
中々見つけづらいものかな…と思っています。
少なくとも、私がシングルサインオンを扱い始めた際は、わりと苦労しました。

というところで本記事シリーズでは、SE様のようにシングルサインオンを導入なさる側の皆様を意識し、
ベース知識を得るための情報源となるべく執筆していきたいと思います。
もし記事をお読みくださったら、ベンダ候補として弊社も加えていただけますと嬉しいです。

まずは何より、お客様や社内の皆様に意義を語る必要があったりしますよね。
というわけで、この第１回目の記事では、なぜシングルサインオン化すべきかについてざっくり書いてみます。

なぜシングルサインオン化すべきか

Before ⇒ After の形で、なぜシングルサインオン化すべきかを書いてみます。

シングルサインオンする前の姿、つまりユーザが各アプリケーションへ個別にサインオンする形は、様々な視点で問題があります。

#	視点	内容
1	ユーザビリティ	アプリ毎にログイン作業をするのはユーザにとって負担になる。アプリ毎に異なるパスワードポリシだったりするとさらに辛いことに…。
2	セキュリティ	アプリケーション毎にログイン処理を開発した場合、その分セキュリティ脆弱性の存在可能性も増えてしまう。仮に１つのアプリの脆弱性でパスワードが漏洩し、それが他アプリへのリスト攻撃の引き金になったりすると酷い状況に…。
3	コスト	アプリケーション毎にログイン処理を開発した場合、その分開発やメンテナンスコストがかかる。上記したようなセキュリティ問題を発生させないための開発・テストのためには高いコストがかかる…。

シングルサインオン化された姿では、以下のように問題が解消されます。

#	視点	内容
1	ユーザビリティ	一度ログインすれば、認証連携済みのアプリ群を全部利用できるので楽。
2	セキュリティ	シングルサインオンサーバのログイン実装を使う事で、高いセキュリティを確保できる。2段階認証やFIDO2/WebAuthnといった高度な認証方法を採用することでさらにセキュアにできる。
3	コスト	Webアプリケーション側は、シングルサインオンサーバとの認証連携をするのみで認証を完了できる。認証連携も、SAMLのような標準プロトコルのライブラリが出揃ったので、比較的楽に実現可能。

今回は、以下のことを記しました。
・本シングルサインオン解説シリーズの位置づけ
・なぜシングルサインオン化すべきか

次回以降、大枠から段々詳細に向かうよう執筆していく予定です。