そうだね、結局はプレミアムを払える顧客と払えない顧客を差別化する巧妙な方法に過ぎないよ。最終的な目標は、できるだけ多くのお金を引き出すことなんだ。

これは完全に間違ってるよ。OIDCやSAMLにSCIMを加えるのは、企業向けサービスプロバイダーのデフォルトにすべきだし、「それじゃダメだよ」。自分のIDPをデフォルトとして提供するのはいいけど、顧客が自分のIDPを設定できるようにするために解決しなきゃいけない問題は、サービスの設計やアーキテクチャにとって重要なんだ。これらのプロバイダーが特別扱いしているのは、最初に自分たちのサービスとIDPの統合を正しく作らなかったからだよ。プロビジョニングと認証はセキュリティにとって重要で、顧客に自分のIDPソリューションを使わせることを強要するのは、顧客に対して悪影響を与えているんだ。

自分でホストしているアプリがいくつかあって、SSOが企業向け機能なんだ。家族や友達をそのアプリに招待したいけど、SSOのために追加で2万ドルも払いたくないんだ。でも、SSOが使えたらすごく便利だよね。「ねえ、Xのログインって何だっけ？」とか「Yのパスワードをリセットしてくれる？」って質問が一気に減るし。

特に顧客がテクノロジー系の会社じゃなかったり、ITスタッフがあまりやる気がない場合はそうなるね。SCIMを加えると、ITの人たちが「他のものとより良く合わせるために変更する」ってなって、もう楽しいことがいっぱい起こるよ。

あなた、Stripeで働いてて、名前がSCIMで同期してない問題があるのかな？その場合、私は顧客で、たぶんあなたのせいだと思ってるよ ;)

そうそう、前の職場でこれに悩まされてたけど、サポートの負担がひどかった。Azure AD/Entra ID（MicrosoftのIDP）が一番多かったけど、これについて全然知らないITの人が多すぎて驚いた。会社が問題をこっちに回してくるけど、それは彼らの問題なのに。「ねえ、MFAが必要ってチケットが来たけど、アカウントはEntra IDになってる。」とか。「ITチームに連絡して返して。」とか。「そのITチームがチケットを開いたんだよ。」って怒鳴りたくなる。設定手順を守らない会社も多かった。Terraform、Powershell、グラフィカルな設定を提供してたけど、Terraform/Powershellを使った人は片手で数えるくらい。エラーメッセージに慣れちゃって、「ああ、これ彼らの側で設定が間違ってたんだな。」ってわかることが多かった。$CustomerITと4回電話して、ちゃんと設定されてるって言われたけど、その後は連絡が来なくなった。結局、頭の良い人がレビューして、設定を終わらせた。ドキュメントもUIの変更で古くなって、1日かけて見直して更新してた。

この問題を解決するために、SSO/SAMLの統合と設定をするスタートアップを始めたんだ。[0] 5年前にHNでローンチして、今ではOpenAI、Cursor、Vercel、その他千のアプリのSSOを支えてるよ。最初の設定ステップがユーザーにとって辛いってのも分かったから、エンタープライズの管理者が問題を解決できるセルフサービスウィザードも作ったんだ。[2] エンタープライズのアイデンティティシステムや大規模組織のユーザーライフサイクル管理の複雑さは本当にすごいよ。全体が変なエッジケースで構成されてるみたいで、SCIMやRBAC、MFAなんかを追加するとさらにややこしくなるしね。（IAMと開発ツールの交差点で苦しんでる人がいたら、うちでは採用中だよ！プロフィールにメールアドレスあるからね :))

私の意見としては、SSO税は完全に正当だと思う。SSOは安全に管理するのが面倒で複雑な機能だからね。実際、多くのSSO実装はセキュリティの脆弱性に関してはあまり安全じゃない。ほとんどの会社はGoogle OAuthを使うことで、同等のセキュリティとより良い体験を得られるんだ。みんなに提供されるべきセキュリティ機能にお金を払う必要があるっていう主張は、Google/Microsoft OAuthを提供しているなら理解できないよ。ほとんどの小さな会社は最初からOktaなどではなく、Google/Microsoft OAuthを使うだろうしね。もし本当にSSOが必要なら、大量のユーザーを管理したり、SCIMプロビジョニングをしようとしているからだと思う。その場合、すべてがスムーズに動くようにベンダーに負担がかかるだろうし、そうでなければベンダーにお金を払うことになる（私たちのように、Stytchの創業者の一人として偏見があるけど）。私たちは企業がSAML実装を安全にするためのオープンソースライブラリ、SAML Shield [1]を作ったんだ。これが社内のSAMLを維持するチームの負担を減らす助けになればいいけど、現実的には確かに負担なんだよね。

最近、SaaSサービス用にこれ（OIDC、SAML、SCIM）を扱ってるおすすめのベンダーやライブラリってある？みんなが請求にStripeを使うみたいに、認証に使うやつ。

ちょっと気になったんだけど、なんでSSOプロバイダーにGitHubを選んだの？自宅のラボ用にローカルSSOを考えてて、パスキーとGoogleアカウントを結びつけるのを悩んでるんだ。

ちょっと確認したいんだけど、大きな組織がSSOを必要とすることで、その費用を負担しているってことを言ってるの？

でも、大きな価格に敏感じゃない顧客が、価格に敏感な顧客のためにお金を払っていることを忘れないで。 みんなが低価格でエンタープライズ機能を得られると思うのは間違いだよ。実際には、市場のセグメンテーションがないと、全員に対して一律の価格は非エンタープライズ価格よりもエンタープライズ価格に近くなるんだ。これを「SSO税」と呼んでもいいけど、低価格を「非企業割引」と呼ぶのも同じくらい正しいよ。

この議論に冷静さを加えてくれてありがとう。結局、これは経済の問題で、これらの機能を追加して維持するためのR&Dの努力は簡単じゃないんだ。

Patio11の表現が好きだな。> 「SSO税」（企業がセキュリティ機能に対して追加料金を請求すること）を考える正しい方法は、「強力なエンジニアリングチームが支えるデュアルユース製品を、他の方法よりもずっと安く提供されている。洗練された企業がその負担を分担している」ということだ。それに、TLS/SSLも以前はエンタープライズ専用だった（少なくともeコマースサイトでは）。無料のオプションもたくさんあるし、サードパーティのサーバーやライブラリもある。最終的には、SSOが無料版でなくても、少なくともエンタープライズプランに限定されないことを願っているよ。

SSO税は主に技術やサポートコストとは関係ないってことを指摘する価値があるね。これがトップに来てるのは驚きだわ。私の経験や、下のコメントをしてるほとんどの人の経験では、SSOは彼らが抱える最大のサポート負担なんだ。SSOはサポートに余分なコストがかかるから、余分にお金がかかるんだよ。市場セグメンテーションはいい副産物だけどね。

主に技術やサポートコストとは関係ない サポートコストはゼロじゃないけどね。私は多くの法人顧客を持つ会社で働いていて、SSOのサポートチケットがたくさん来るんだ。人々はドキュメントを誤読したり、私たちの推奨に反して設定したり、システムを移行したり、システムを統合したり（買収などで）してるから...

私はとても小さなビジネスを運営してるけど、SSOはまだ機能優先リストのかなり上にあるんだ。SSOを低いエントリーポイントで提供している競合のソフトウェアやサービスを使わずに済ませてるよ。

それに、エンタープライズ顧客は手間がかかるし、営業サイクルも長いし、コンプライアンスやオンボーディングの作業も時間がかかる。これを価格に組み込むのは非常に正当な理由があるし、こういう会社が価格に鈍感に見えるのも同じ理由だよ。もし彼らがより良い価格を提示する人が並んでいたら、きっとそれを受け入れるだろうね。

でも、大きな価格に敏感じゃない顧客が、価格に敏感な顧客のためにお金を払っていることを忘れないでね。 それって、彼らがその顧客の損失を十分に補っているってこと？サービスの根本的なコストは何なの？実装が書かれたら、ベンダーにとってのコストは基本的にゼロだから、利益率はめちゃくちゃ高いんじゃない？

そうだね - これは企業と中小企業の違いで、「あなたの収益は？」みたいな質問をする必要がない。企業は必要としてるけど、中小企業はそうじゃない。

でも、VPNにサインインせずにメールをチェックできるのはすごくいいよね。

誰かがそのアイデアを推進するためにたくさんのお金を払ったに違いない。 それは疑わしいね。中央値の企業IT運用がIdPを運営するのがどれだけひどいかに気づいたら、そのアイデアは自分で広まるよ。

プレミアムプランやビジネスプランの多くはSSOを提供してないよね。10回中9回はエンタープライズじゃないとダメって感じ。

SSOはサポートするのに一番お金がかかる機能だった。サポートリクエストの中で一番多いもので、その中のかなりの割合がエンジニアが顧客（とそのITチーム）と電話をしなきゃいけないものだった。これが実際の流れだって確認できるよ。SSOは簡単だとか自己解決できるべきだと理論を立てることはできるけど、実際にはSSO機能はサポートやエンジニアリングに不釣り合いな負担をかけるんだ。高い席を100席買っている顧客のためにSSOサポートをしていると、正当化しやすいけど、3ライセンスの小さな店のSSOをデバッグしていると、リードが新しい競合に目を向けた瞬間にすぐにやめちゃうから、そんなのやる価値はないよ。

ごめん、でもそれは機能がどちらの側でも使いにくいってことだから、少なくとも50%はその問題だよ。良いドキュメントを提供する？それはどう？誰かが問題を抱えたら、その都度ドキュメントを作成していけば、時間が経つにつれてその質問はかなり減るよ。編集：初めてこれを実装する人には、1) アプリ内で新しいアカウントを作成したときに何が起こるか（ローカル） 2) SSOプロバイダー内で新しいアカウントを作成したときに何が起こるか 3) セットアップ中に既存のアカウントがどうなるか、現在のユーザーが移行されるのかどうか（または両方のサインインを使えるのか）を明確にするべきだよ。

これに付け加えると、そういう業界の多くのビジネスは「IT」じゃなくて、ひどい運用技術ネットワークやセキュリティを抱えてるんだよね。それでも、化学供給業者や運送会社、完成品の製造業者、さらには小さな地域のISPにとっても、ビジネスは「国にとって重要」なのに、ITやセキュリティを見てるスタッフが数人いるかどうかって感じ。SSO税は、知らず知らずのうちに多くの障壁や問題を生んでるよ。何かが変わらなきゃ。

このコメントでスッキリした。GoogleやDiscordをBetter Authで設定するのは、私の家庭プロジェクトの一つでは特に難しくなかったから。

それは奇妙だね。どうしてユーザー管理をGoogle SSOにアウトソーシングするって呼ぶの？それはほとんどのスパムシステムが提供する機能で、認証するためのものであって、真剣なビジネスアプリケーションじゃないよ。