公開後に自分で考えたことと、いただいたコメントのメモ。
ID/Password の再入力が不要ということを強調してしまったけど、それはログインセッションの有効期限による話かなぁ… ログインセッションが短いと、認証基盤がまとまってても ID/Password 入力の回数は増えて面倒。ただセッションの有効期限とアクセス可能な情報のセキュリティレベルの組み合わ文字数
あといまだに
- 複数サービスで ID/Password を使いまわしている（あかん）
- １つのID/Password で複数のサービスが利用できる（SSO）
これだけみると漏洩する情報量って同じなのでは？と思ってしまうのよね。これは一部を端的に見ているからだけども。
業務系SaaSが「SSOに対応しました！」っていうのは便利でもあるけど、これまで（パスワードをバラバラにしておけば）業務データがまるっと漏洩するリスクは下げられたかもしれないものが、１つのパスワードで全部にアクセスできる可能性ができたということになるのでは？
まぁそのためにたいていのSaaSは、例えばログインした本人以外の管理情報を扱う（管理者権限で他人のデータが見えるとか）場合には、再認証とか 2FA とか通知が飛ぶとかの対策が必要なのだよね… （GitHub の設定いじるときにはパスワードの再確認が必要なアレとか）
結局ユーザー側のリテラシーが求められるアカウントセキュリティむずかしい
某業務系SaaS（勤怠管理系）は去年あたりに同社の関連サービス群でSSO化したんだけど、今年に入ってからログインセッションが30分に短縮された。 これはセキュリティを加味しての対応だろうけど、30分放置でまた再ログインさせられるというのはなかなかに面倒くさいというのが、ユーザとしての感想。
コメントいただいた
SSOは「API連携」時代前によく使われていた印象。SNSでログインできるだけではなく、ログイン状態の同期、ログアウト時の挙動などまで広げて考えると、顧客の要件、IDaaS/OIDCの価値とかも認識されていくと思う。
— 👹秋田の猫🐱 (@ritou) 2019年12月9日
シングルサインオンのひとことで片付けない - TMD45'β'LOG!!! https://t.co/eA1Ww4ClQj
たしかに。ついつい「ログイン」のことばっかり考えてて、その "状態" の同期とかログアウト（セッションの破棄）とか全然記事に入ってなかった！
この比較でいうと漏洩した時の情報量が同じならば、漏洩を防ぐコストが小さい方が良い。不正利用対策にコストをかけられるIdPと連携するメリット、IdP陥落時の影響範囲のリスクという話になる。 https://t.co/8MZd6ZPYSE
— 👹秋田の猫🐱 (@ritou) 2019年12月9日
ですね。
システム開発、視野が狭いとほんとうにあかんということがよく分かる（身に染みる＞＜）
