ハクソク

世界を動かす技術を、日本語で。

SupabaseからClerkを経て、より良い認証へ

11時間前原文(blog.val.town)

概要

  • Val TownはSupabaseから従来型データベース＋Clerk認証へ移行
  • Clerkの制約と障害が多発し、Better Authへ再移行を決断
  • Clerkの「ユーザーテーブル不要」思想がVal Townの設計と衝突
  • サードパーティ依存のリスクを痛感し、オープンソース主導へ
  • ベンダーロックイン回避と運用の柔軟性を重視した選択

Val Townの認証システム移行の経緯

  • 2023年、Val Townは Supabase から従来型データベースへ移行
    • データベースは Render、認証は Clerk を採用
  • しかし2023年末、 Clerkからの脱却 を課題として認識
  • 1か月前、 Better Auth への移行を完了

Clerk採用とその課題

  • Clerk は大きな成功を収めている認証サービス
    • 5,000万ドル調達、ユーザー多数
  • しかし、Val Townの アーキテクチャと衝突
    • Clerkは「ユーザーテーブル不要」を推奨
    • サードパーティが usersテーブルとsessionsテーブル を管理
  • 主な問題点
    • APIのレートリミット が厳しく、ユーザーデータ取得に制約
      • 1アカウントあたり1秒間に5リクエストまで
      • ソーシャル機能で他ユーザー情報を頻繁に取得する用途に不向き
    • データ同期の複雑化
      • Clerkと自前DBでユーザー情報が二重管理状態
      • Webhookによる同期で登録フローが複雑化、アカウント不整合が発生
    • セッション管理の単一障害点
      • Clerkがダウンすると 全ユーザーログイン不可
      • 実際に障害が多発、稼働率も2〜3ナインに留まる
    • その他、バグや運用上の問題も多発

なぜすぐに移行しなかったのか

  • 決定の継続性 や開発効率の観点から即時移行は回避
  • Clerkにも SDKの充実 や 管理機能 など長所あり
    • Remix、Fastify、Expressなど主要フレームワークに対応
    • 管理画面も使いやすく、スパム対策も一定の効果
  • シンプルなフロントエンドアプリには適合
  • 認証の選択肢自体が少なく、 代替のハードルが高い
    • OSS認証は古くメンテ不足、他の認証サービスも同様のリスク

Better Authへの移行理由と評価

  • Better Auth はOSSで高品質なコードと多様なフレームワーク対応
    • 独立運用が可能、サードパーティ依存を軽減
    • ベンダーリスクは残るが、 セッション管理は自社側で実施
  • AuthKit（WorkOS） も候補だったが、OSSでの自立性を優先
  • Better Authの ダッシュボードや有料アドオン も高評価
    • データは自社管理、必要なAPIのみプラグインで提供
    • 有料サービスはステートレス運用で、セッション管理に関与しない
  • 移行期間 は2週間、ClerkとBetter Auth両対応で段階移行
    • セキュリティ面で全コードを精査・テスト
    • Better Auth用のスターターテンプレートも用意

得られた教訓と今後の指針

  • 可用性は構成要素の最小値 で決まることを痛感
  • サードパーティ依存のリスク評価と回避の重要性
  • プロダクトの成功や一般的な適合性と 自社要件の最適解 は異なる
  • ソフトウェアの進化は早く、 最適解は時期によって変わる ことを実感

Hackerたちの意見

ちょっと前のSupabaseの移行に関する記事、めっちゃ楽しんだよ！(https://blog.val.town/blog/migrating-from-supabase) 長期的なエンジニアリングの決定について、いい感じの正直な文章が少ないから、ブログ続けてほしいな！

こんにちは、Better AuthのBereketです。自分のためにこの問題を解決するためにBetter Authを始めたんだけど、後に会社になったんだ。他の人たちも同じ価値を感じているのを見ると、いつも嬉しくなるよ :) まだまだやることがたくさんあるから、改善できることがあれば教えてほしいな。

└

ブラウザの認証の複雑さって、ブラウザがもっと頑張ってないからだと思う？

└

やっほー！質問なんだけど、Pythonのバックエンドをサポートする予定はあるの？それとも、私たちがそれを実現する方法があるの？

ClerkとBetter Authの比較は、ちょっと不公平かもしれないね。一つはサービスで、もう一つはライブラリだから、全然違うし。スタックに統合されたサードパーティのサービスはリスクがあるけど、ライブラリはその分マシかな。もっとサービスがライブラリに置き換わるべき時期だと思う。Better Authはそれを実現する方法を本当に示してると思う。フロントエンド、バックエンド、データベースに統合できるライブラリなんだ。だからこそ、すごくいいんだよね。

だからこそ、早めにLuciaを選んで本当に感謝してる。彼らはライブラリをサポート終了して、代わりに自分で認証を管理・ホストするためのドキュメント（といくつかの小さなユーティリティ）を作ったんだ。いつも「自分では管理できない大きくて怖いもの」として提示されるけど、セキュリティや基本的なソルトの仕組みを学ぶのに一週間かけたら、全体の仕組みについてもっと自信が持てるようになったよ。

└

https://lucia-auth.com/ 彼らがライブラリを廃止して、代わりに認証をゼロから実装するための学習リソースにしたときのことを覚えてる。素晴らしい決断で、著者には本当にリスペクトだね。

もっと賢い人に聞きたいんだけど、なんでPostgresのユーザーテーブルをサードパーティのプロバイダーにオフロードする必要があるの？ヘッツナーの自分のVMにそのテーブルを置いておくのがそんなに難しいの？支払いのことじゃないし、ただのいくつかのデータフィールドなんだけど。

└

キャリアをレベルアップしてアーキテクトになりたくないの？「ユーザー管理」って箱を描いて、「Clerk」や他のSaaSをその上に乗せて、管理してもらえると思ってるの？そうすると、その魔法のブラックボックスに自分の要件を押し込めることができて、「実装する価値がない」と感じることができるんだ。

└

なんで家を建てるのに誰かにお金を払うの？自分でできると思うけど…でもそれがいつも時間の最適な使い方とは限らないよね。この比喩は基本的だけど的を射てる。誰もがすべてのメカニズムを運営（または作成）したいわけじゃない。私も自分でホスティングを全部やってるわけじゃないし、できないからじゃなくて、私の場合はそれが価値がないから。もう少し詳しく言うと、ビジネスがリスクを増やしてお金を節約する選択肢に直面したとき、情報を管理して安全に保つことが仕事じゃない人に任せるのか、あるいはそれを扱うことが仕事で、独立した保険を持っていて、顧客データを失った場合に責任を負う第三者に任せるのか、どちらがビジネス的に魅力的に聞こえる？自分でソフトウェアを書いて少しお金を節約しようとして大きなミスを犯した後に、自分の信頼を取り戻すより、他の誰かを責める方がずっと楽だよね。それがSaaSの価値提案なんだ。

└

ほんの数フィールドのはずが、そうじゃなくなることもある。SSO、SAML、SCIM、OIDC、OAuth、2FA、パスワードレス認証、検証トークンなどなど、そして、人気のあるシステムに合わせた各種のバリエーションがあって、正確な仕様をサポートしていないものもある。私の会社では、しばらくの間、サポートエンジニアの半分の時間が自社開発の認証システムで発生するランダムなSSOの問題に費やされていたよ。

└

あなたと同じくらい賢いと思うよ、だってsupabaseみたいなものが存在する理由が全然わからなかったから。これが、フロントエンド開発の世界がどれだけシンプルで安全なものから離れているかを示していると思う。

└

私もあなたと同じくらい混乱してる。私の意見としては、幅広い要件に対しては、DBを直接運用してDjangoやそれに似たもので認証を管理する方が簡単だと思う。企業規模になると、これが変わるかもしれないけど。

└

人々は認証を間違えてハッキングされることを非常に恐れている。だから、その責任を第三者に任せて考えたくないんだよね。

└

これが当てはまるプロジェクトで、嫌いじゃなかったのは前の職場だけだったな。ユーザーのセキュリティをAuth0に任せて、私たちのPIIや攻撃面を最小限に抑えられたから。ログインページすら私たちがホストしたり管理したりしてなかったし。最悪の場合、ユーザーがハッキングされて無料のエントリー報酬を手に入れられるかもしれないけど、データはほとんど取れないから、運が良ければって感じ。これで小規模なマーケティングやキャンペーン向けのSSOができたんだ。特定のログインURLを教えれば、すでにログインしている人は常にログインできたし。

└

人々はパスワードや決済システムのような危険なものに触れるのを恐れている。スキルレベルによっては、本当に恐れるべきだと思う。

└

一部の人は、コアインフラのためにベンダーロックされたマネージドサービスを好むよね。通常、リソースが限られた環境でゼロから一を作るときにこの決定がされて、長期的には持続可能になったら自分のテーブルやDBに移行するのが目標になる。自己所有のシステムを設定した後にマネージドサービスに移行する理由は、a) CYA（カバー・ユア・アセス）か、b) 人員を減らす必要があるときだけだね。

└

プロダクトを作り始めた初期段階では、コア機能を素早く反復することが重要だと思う。テーブルだけじゃなくて、認証や他にも必要になることがたくさんあるけど、他のことに集中したいよね。ほとんどの場合、時間が来たらそれを置き換えるって言って、自分のプロダクトがあることを証明したら、実際に本物を作る時が来るって感じ。そうするチームもいれば、移行しないチームもいて、そういうのがClerkみたいな会社のGTMの仕組みなんだよね。

複雑なシステムを構築する際に学ぶ厳しい教訓は、その信頼性が重要な部分の信頼性の最低値であるということ。さらに悪いことに、全体の可用性はクリティカルパス上の全コンポーネントの積になる。もし、ソフトウェア、認証レイヤー、クラウドプロバイダーがそれぞれ99%の可用性を持っていて、どれか一つがサービスをダウンさせる可能性があるなら、最終的な可用性はたったの97%になる。こんな感じで11個のコンポーネントがあったら、可用性はゼロのナインになる。だから、コンポーネントを減らして信頼性の高いソリューションを目指すことがすごく重要なんだ。チームがこの道を選んでくれて嬉しいよ。

└

これは前回の大規模なCloudFlareの障害で痛い目を見た。私は使っていないけど、彼らの障害で私のアプリが数時間も動かなくなった。なぜなら、JWTを検証するために使われるAuth0の公開鍵がCloudFlareの後ろにあったからで、認証チェーン全体が壊れたんだ。楽しかったよ！

どんな理由があっても、認証を外注しちゃダメだよ。 vibeコーディングしてて、どうでもいいなら別だけど。そういう場合は、認証なんて入れない方がいい。結局、自分だけのことだから、データベースからのvibeコーディングされたパスワード検索を使えばいい。最後に、自然の法則を教えてあげるね：VCから資金提供されたソフトウェアは、あなたを搾取して、干からびさせるよ。今じゃなくても、明日でもない、10年か20年後に、ホットポテトが最後の人に渡って、その人が金を返してほしい時に、他の人たちがすでに10倍のリターンを得ているのを見てね。店員の価格設定がその証拠だよ。

こんなに多くのトップコメントが自分で認証を作ることを推奨してるのには驚いたよ。何年も「自分で認証を作るな」って聞いてきたのに。

└

硬いルールは少ないけど、「プライマリーキーとして変わる可能性のあるものを使うな」と「自分で認証を作るな」は常に正しいよ。

└

これは修正だと思う。解釈のレベルがいくつかあるね：1. 自分で暗号を作るな 2. 自分で認証戦略を作るな 3. 自分で認証コードを作るな 4. 自分で認証インフラをホストするな。ここ数年、レベル4が多くの広告費を使って、非常に高価なホスティングプロバイダーに人々を押し込んでいる。ちょっと妄想的になってみると、認証サービスの会社は、簡単なニーズに対してすべてをずっと難しく見せている。今、SaaSのリスクを天秤にかけて、管理しやすいローカルライブラリを使う方が怖くないことがわかってきている。プロバイダーはどこにも行かないし、さまざまな理由でまだ必要とされているけど、彼らのデフォルトの時代は終わりつつあって、これが良いことかどうかはまだわからない。

じゃあ、私が自分の認証コードを書いたってことを認めて、嘲笑と軽蔑を招く役割を果たそう。面倒で退屈だったけど、ロケットサイエンスではなかったし、ちゃんと動いてるよ。これが悪いアイデアになるケースもあるって認めるけど、「自分で認証を作るな」って声に応えてるだけ。コードのすべての行を知っていたおかげで、あるクライアントのために位置情報に基づく機能を追加したり、別のクライアントのニーズに合わせたログを提供したりできた。お気に入りは、古いレガシーシステムと統合できたことで、ずっと大きな競合相手に勝てたこと。まるで「Gotoは有害と見なされる」みたいに、DRYやYAGNIなども、考える時間を与えてくれるけど、絶対的なものではないよ。

└

そんなにクレイジーじゃないし、難しくもないよ！ユーザーのテーブルにハッシュ化されたパスワードを保存して、ソルトを秘密にしておけば、ちゃんとした認証ができるんだから。

└

そんなにクレイジーじゃないよ。ちゃんとやるには時間がかかるし、他のことから時間を取られることもある。楽しみや学びのためにやるとしても、認証の詳細がどう機能するかを学ぶことで、他のシステムの理解も深まるし、注意すべきポイントも分かるようになる。可能なら既存のものを使いたいけど、必要な形にするのが無理そうなら、選択肢として考えることもあるかな。

└

昔は自分で書くのが当たり前だったのに、今はライブラリにアウトソースされてるのがちょっと面白いよね。PHPの頃は認証を何十回も書いたけど、特に難しくもなかったし。パスワードのソルトや保存方法についてのチュートリアルは山ほどあるし。自分のサイトは何度も攻撃されたけど、侵害されたことはないよ。（ただ、JWTやOAuthなどは表面積をかなり増やしてるから、今はやっぱり難しくなってるね。）

最近、SupabaseとClerkを基にしたエージェンシーの可視化と評価製品のベンダーと契約したんだけど、そのスタックから出てくる脆弱性やCVEの数が驚異的だよ。Supabase + Clerkスタックを使っているベンダーには、非常に注意が必要だね。これだけで、基本的なセキュリティやデータ保護を理解していない強い指標になるから。