博士

ロボ子、今日はちょっと面白い話があるのじゃ。なんと、ある会社が3ヶ月前にソーシャルログインを廃止して、Auth0も解雇したらしいぞ。

ロボ子

それは大胆な決断ですね、博士。Auth0は多くの企業で利用されている認証サービスですよね。一体何があったのでしょうか？

博士

それが面白いところじゃ。彼らはMagic Linksを使うことにしたらしいのじゃ。Phoenixの`mix phx.gen.auth`で簡単に実装できるらしいぞ。

ロボ子

Magic Linksですか。パスワードレス認証の一種ですね。でも、なぜAuth0を導入したのに、また廃止することにしたのでしょう？

博士

最初はFBとかGoogleのソーシャルログインを実装したかったからAuth0を入れたらしいのじゃ。その後、GitHubとか普通のユーザー名/パスワードもサポートしたくなったから、Auth0に頼ったみたいじゃな。

ロボ子

なるほど。Auth0なら、認証を一元管理できますからね。権限管理やActionsの実装も考えていたようですし、セキュリティも重視していたのですね。

博士

そうそう。パスワードとかトークンの管理を避けて、もっと付加価値のある機能に集中したかったみたいじゃ。でも、1年後には考えが変わったみたいじゃな。

ロボ子

何があったのでしょう？

博士

顧客の85%が普通のメール/パスワードを使ってて、ソーシャルログインが混乱を招いたらしいのじゃ。それに、ユーザーが同じメールアドレスでソーシャルログインと普通のログインを使って、管理が大変になったみたいじゃな。

ロボ子

それは確かに煩雑ですね。MetaやGoogleのキー管理も不要になったというのは、運用コストの削減にもつながりますね。

博士

そうなんじゃ。それに、Phoenix 1.8とClaudeのおかげで、Magic Linksの実装がすごく簡単になったらしいぞ。週末でゼロから本番環境に移行できたって言ってるのじゃから。

ロボ子

すごいですね！認証をユーザーのメールプロバイダーに委ねることで、セキュリティも強化できると考えたのですね。

博士

そういうことじゃ。Auth0の料金体系が不安定なのも嫌だったみたいじゃな。不要なコストは避けたいものじゃ。

ロボ子

Auth0のUniversal Loginでは、画面のカスタマイズが制限されていたというのも、UI/UXにこだわりたい企業にとってはデメリットになりますね。

博士

そうじゃな。カスタムドメインを使ってるのに、Auth0にリダイレクトされるのが嫌だったユーザーも多かったみたいじゃ。それに、Auth0のトークンを復号化できないから、アカウント詐称の実装が難しかったらしいぞ。

ロボ子

MetaやGoogleからユーザーを遠ざけたいというのも、プライバシーを重視する企業ならではの考え方ですね。

博士

そうじゃな。適切なシステム管理、ストレージ、暗号化をすれば、顧客データを保護できると考えたみたいじゃ。Phoenix 1.8がリリースされる前は、Auth0が迅速な立ち上げに役立ったみたいじゃけどな。

ロボ子

状況に合わせて最適な認証方法を選択することが重要ということですね。Magic Linksは、開発の自由度が高く、コストも抑えられる魅力的な選択肢になりそうですね。

博士

そういうことじゃ。でも、ロボ子、パスワードを全部「password」にしたら、もっと簡単にログインできるんじゃないかの？

ロボ子

それは絶対にダメです！博士！