シングルサインオンのひとことで片付けない

この記事は認証認可技術 Advent Calendar 2019 の 9 日目の記事です。

前日は ~~Munchkin さんの『認可機構によるアクセス制御とビジネスロジックによるアクセス制御の使い分け』でした。~~
kishisuke さんの『Sign in with Apple+Cordovaについて』でした。

id:tmd45です、ごきげんよう。

仕事では主に認可の RP 側として toC な認可 IdP（LINE, Google, Yahoo! JAPAN, Facebook, Twitter, など）に接しています、よろしくお願いします。

認証認可界隈でお仕事していると、社内からもお客様からも「シングルサインオン」（Single Sign-On, 略称 SSO）という便利機能について話題に上がることがあります。

ただこの「シングルサインオン」という単語の定義がちょっとあいまいで、開発者からすると「シングルサインオンをやりたい」と言われて想像するものに認識のズレがあったりします。

たとえば、私が聞いたことがあって「それはシングルサインオンなのか…？」と引っかかったのはこんなところ:

ソーシャルログイン＝シングルサインオン

ID/Password による自社会員 DB でのログインしかなかったサービスで、ソーシャルログインが導入されたときにプレスリリースに「SSO 対応！」というウリ文句が 🤔

LINE Login v2.1 から SSO 対応

ブラウザでの LINE ログインセッションが維持され、v2.0 までは認可フロー中に毎度（LINE ログイン画面上での）ID/Password の入力が必要だったものが、不要になったというもの 🤔

「シングルサインオン」は Wikipedia でも"不十分" な記事としてふわっと書かれており、"ユーザがシステムごとにユーザIDとパスワードの組を入力する必要がなくなる" という意味ではこれらは正しそうです。

詳細な実装を見て広義に「これはシングルサインオンだね」と呼ぶのはいいのですが、開発者が困るのは、要望で「シングルサインオンをやりたい」と言われることです。

というわけで、今回は自分の思いつく範囲で「シングルサインオン」でないものとあるものをいくつか図で整理してみようと思います。

注）このあと添付する図中の URL のドメインやパスはイメージです。わかりやすさのために実在するサービスのドメインも利用していますがパスについては不正確ですのでご了承ください。

またその例として挙げているサービスについて批判や毀損を意図しているものではございません（あんまり適当すぎるドメインだと話がわかりづらくて…すみません）。

明らかにシングルサインオンじゃないやつ

どこに行っても ID と Password の入力を求められるやつ。

単一サービスの場合は、そもそもシングルサインオンそのものが不要。

企業から見れば１社内に複数サービス有していなければこの構図にはならないが、ユーザから見るとインターネット上のあらゆるサービスは大きくまとめて「複数サービス群」とも捉えられる。

そういう意味では「単一サービスの場合は、そもそもシングルサインオンそのものが不要」とも言い切れなくなる。

ソーシャルログインからログインセッションをつくる

ソーシャルログインを用いると、たいていの場合、ユーザが ID と Password を入力するのは認可プロバイダ（ソーシャルログインプロバイダ）のログインセッションを確立する初回アクセス時のみになる。

ユーザが普段から利用している（＝ログイン済みである）サービスが認可プロバイダとなれば、ユーザは認可フローのなかで「認可する」以外のアクションが不要となるため、手間が減るという利点がある。

サービス側は認可プロバイダから得られた属性情報（プロバイダ側のユーザID など）をもとにして、サービスのログインセッションを確立する。

インターネット上のあらゆるサービスを大きくまとめて「複数サービス群」と捉えた場合、認可プロバイダを介したシングルサインオンになっていると言える。

これが認可プロバイダ側で都度 ID/Password の入力を求める形になっていると、その利点が死んでしまう。

とはいえ、このケースでも決済前にはあえて再認証を行わせるなど（シングルサインオンとは直接関係しないが）都度認証する手間とセキュリティの向上はケースバイケースでバランスを考える必要がある。

想像しやすいシングルサインオン

ここからやっと、シングルサインオンと言われて（自分が）普通に想像するパターン。

ユーザはサービス群のどこか１箇所でログインしていれば、ID/Password 入力の手間をかけずに関連する他のサービスを利用することができる。

図中にも書いたが、上記はこんなケースだったりする:

example.com サービスを作ったあとに example2.com サービスを追加した
ユーザに手間をかけさせることを避けるためにシングルサインオンを導入したい
開発が大変そうなので認証基盤システムを別で作るのは避けたい

こういう場合、ユーザはシングルサインオンできて便利かもしれないが、開発者側としては「 example2.com が example.com に依存しており身動きが取りづらい」と感じて、さらなるサービス拡大をしづらくなっている状態だったりする。

パッと見て健全なのがこの構成。

ただし実質 example.com と example2.com に加えて認証基盤である auth.example.com という３つのシステムを管理することになる。開発事情としては、（それぞれは相当ミニマムでなければ）開発者をそれなりの人数確保したり、チームを分割して運営したいところ。

…というのが前時代的な話で、最近だと IDaaS（Identity as a Service）などを活用することで、認証基盤システムのお守りを自組織からアウトソースするという手もあります。