ハクソク

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

Launch HN: Better Auth (YC X25) – TypeScript用認証フレームワーク

371日前

概要

  • Better Auth は、TypeScript向けの包括的な 認証フレームワーク を提供
  • サードパーティサービス不要 で、自分のデータベース・バックエンドに直接組み込むことが可能
  • 豊富なプラグイン で、シンプルな認証からエンタープライズ向け機能まで柔軟に対応
  • 無料・オープンソース で、商用向け追加インフラも今後提供予定
  • ユーザー主導のカスタマイズ性 と完全なデータコントロールを実現

TypeScriptエコシステム向け新世代認証フレームワーク「Better Auth」

Better Authの特徴と誕生背景

  • TypeScript開発者向けに 認証実装の負担軽減 を目的として開発
  • Auth0 などのサードパーティサービスはデータの所有権を奪い、コストも高額になることが多い—回避策を提案
  • NextAuth などオープンソースライブラリは基本機能のみ—追加要件は自力実装が必要になる課題を解決
  • 組織管理（ワークスペース、チーム、権限など） を簡単に導入できる認証基盤がなかったことが開発のきっかけ
  • プラグインエコシステム により、シンプルな導入からスケーラブルな拡張まで柔軟に対応することを目標とすること

Better Authの主な機能

  • 自前バックエンド・データベース への直接組み込みを実現すること
  • 2FA、パスキー、組織管理、マルチセッション、SSO、Stripe連携 など、多様な認証機能をプラグインで拡張可能にすること
  • 完全なデータコントロール と コードベースへの統合 を保証すること
  • Auth0やClerk並みの機能 ＋ 独自拡張 （例：StripeやPolarとの課金連携）を標準で提供すること
  • 無料・オープンソース として永続的に利用できることを確認

今後の商用インフラ構想

  • 管理ダッシュボード、ユーザー分析、ボット/不正検知、二次セッションストレージ など、ライブラリ単体では難しい機能を提供予定
    • これらは オプションの商用インフラ として提供、必要なチームのみ利用可能にすること
  • https://www.better-auth.build にてウェイトリスト登録を受付中であること

参考動画とリソース

  • YouTube解説動画 で概要や導入方法、コード例を確認できること
    • 概要動画：https://www.youtube.com/watch?v=hFtufpaMcLM
    • コード解説：https://www.youtube.com/watch?v=QurjwJHCoHQ
    • ショート動画：https://www.youtube.com/watch?v=RKqHrE0KyeE
    • TanStack連携：https://www.youtube.com/watch?v=Atev8Nxpw7c
    • 2時間チュートリアル：https://www.youtube.com/watch?v=n6rP9d3RWo8

フィードバックと今後の展望

  • Better Auth は、開発者が 自分のプロジェクトに最適な認証基盤 を簡単かつ安全に構築できることを目指していること
  • ユーザーからのフィードバック を歓迎し、今後の開発に活かす方針であること
  • サードパーティ依存から脱却し、 自律的な認証システム構築 を推進する提案

Hackerたちの意見

いいね！このソリューションは、KeycloakやOry Kratosのようなオープンソースの自己ホスト型認証コンポーネントと比べてどうなのか、興味あるな。そっちの方が統合するのはちょっと手間だけど、自己完結型で自分の環境やコンテナで動くのは便利だよね。ただ、データが自分のアプリともっと密接に統合されてたらなぁと思うこともあったから、そこが狙いなんだろうね。

└

そう、それがまさに私たちの目指しているところだよ。認証をアプリと密接に結びつける理由はたくさんあると思う。君が言ったように、自己ホスト型の認証サーバーを立てて統合するのは、あまり楽しい経験じゃないし、それがサードパーティの認証プロバイダーが人気になった理由の一つだよね。JavaScript/TypeScriptのエコシステムでは、NextAuthのようなライブラリが同じ理由で多くのユーザーを抱えている：使いやすさだね。そして、フロントエンドとバックエンドが一緒に存在して強い型システムを共有するフルスタックTypeScriptアプリの台頭で、すべてのコンテキストを一つの場所に保つことがさらに意味を持つようになった。とはいえ、もしBetter Authを専用のコンテナで自己ホストすることに決めたら、それもできるよ。

└

ほとんどの人は、NextAuthの代わりにBetterAuthを選ぶと思う。基本的には、OIDCや何らかのSSOを統合したいときだね。数ヶ月前に見ていたときに気になったのは、BetterAuthはメールとパスワードをすぐにサポートしているのに対して、NextAuthはメールとパスワードが本質的に安全でないというような説教じみた免責事項があって、パスワードハッシュ化などを自分で実装しなきゃいけない感じだった。それで、NextAuthがこの分野で最初に優位に立っているように感じて、道徳を押し付けているように思えた。BetterAuthはもう少し開発者に寄り添っている印象だね。

Better Authは素晴らしいね、まだ公開されてないなんて気づかなかったよ。今、実際のアプリで使ってるし、いろんな実際のユースケースでも使われてるのを見たことがある。個人的には、認証を実装したいTypeScript開発者にとって、最高のオープンソースオプションだと思う。ダッシュボードについてだけど、これは既存のBetter Authの設定に対するインターフェースになるのかな（例えば、データストレージをカスタマイズしてたら）それとも、あなたたちが認証情報をホストしてるの？この素晴らしいライブラリを作って、こんなにしっかりドキュメントもしてくれて、本当に感謝してるよ。

└

ありがとう、嬉しい言葉だね！はい、既存の設定に直接接続するよ（ダッシュボードは主にUIだし）。実際に「買っている」のは、ダッシュボードの追加機能、例えばボット保護や分析機能など、必要なときに使えるものだよ。まだ価格設定を考えているところだけど、おそらく基本的なダッシュボードは無料になると思うよ ;)

売り切れ！こんなのを待ってたんだ、ここ1年くらい。すごく近いものはたくさんあるけど、「npm install -> 必要な設定を追加 -> npm publish」ほどシンプルなものはなかったからね。これが待ち望んでいたもので、あなたたちが提供しているように見える。新しいHostingerのVPSを立ち上げて、これを乗せてローカルファーストアプリの同期を提供するのが楽しみだよ。もしあなたのドキュメント通りに簡単なら、時間と頭痛を大幅に節約できるね！

数ヶ月前に、better-authのセキュリティ脆弱性を見つけたんだ。チームに報告してから24時間以内にパッチが当てられて、通知が出されて、CVEにクレジットももらった。これが本当のやり方だよ、みんな！このチームは最高だね。コミュニティのリーダーシップ、レスポンスの速さ、開発のスピードが素晴らしい。プロジェクト自体も素晴らしくて、このライブラリは他のものよりもずっと柔軟で、頭を使うのがずっと楽だよ。このライブラリが認められているのを見て、本当に嬉しい。

これ、以下のことは対応してる？ - フェデレーテッドサインイン/サインアウト？NextAuthでは実装するのがすごく面倒なんだ：https://github.com/nextauthjs/next-auth/discussions/3938 - クライアントサイドでのJWTトークンの自動更新？いつも自分でロジックを実装しなきゃいけなくなる。大きな問題は、複数のAPIコールがあって、それらすべてがJWT認証を必要とする場合、JWTの有効性をチェックして更新されるまで呼び出しをブロックしなきゃいけないこと。NextAuthではサーバーサイドでこれを実現するのは不可能で、同じトークンのために複数のリフレッシュコールが発生してしまう。 - SaaSアプリのように、同時に複数の認証セッションを持つことができる？（あなたのイントロの段落はそういう感じだね） - ユーザーが複数のタブを開いて、別のタブでアカウントを切り替えた場合、複数の認証セッションがどう管理されるか - Googleプロバイダーを使ったアカウント切り替え？FusionAuthやCognitoのようなプロバイダーには難しいリクエストのように思える。Googleコネクタを直接使うことはできないけど、初期のOAuth2フローでGoogleと一緒にカスタムパラメータを指定できる汎用OAuth2コネクタを使う必要がある。ユースケースは、ユーザーがGoogleサインインボタンをクリックしたとき、既存のGoogleセッションがあれば、すぐにサインインするのではなく、Googleアカウントのスイッチャー/セレクターに行くべきだということだね。

└
  • 今は無理だけど、すでにオープンな問題があって、PRも進行中だよ。 - JWTは直接使ってないし、セッションは常に状態を必要とするから（ステートレスじゃない）。それに、クライアントとサーバーの両方が自動セッションリフレッシュを処理してるよ。 - うん、複数のセッションや、異なるタブで異なる組織を開くこともサポートしてるよ: https://www.better-auth.com/docs/plugins/multi-session - そう、それは可能だよ。promptパラメータをselect_accountに設定すればいいだけ。
└

複数のリフレッシュコールの問題はどうやって解決したの？フロントエンドでswrフックを使ってる？自分でもどうやってやるか考えてたんだ。

ユーザーがめっちゃ幸せそうだね :) みんなが言ってることに同意だよ。私たちにとっての追加の利点は、ユーザーデータを自分たちのDBにホストできることだから、Indexで掘り下げられるんだ。Clerkはデータをロックインしてて、彼らの「分析」ページはすごく限られてるし。

└

SaaSのために使いやすさと無料プランが魅力的だったので、たまたまClerkを選びました。データロックは「解決可能」でしたが、ソロ開発者にはちょっと手間がかかりすぎました。彼らのWebhookツールを使って、データを同期するために別のInngestサービスを設定しなければなりませんでした。今のところ聞いた話からBetter Authにすごく興味があります！もっと早く知っていればよかったな！

発表おめでとう！Better Authは開発者からの普遍的な愛を受けてるのが本当にわかるよ。ただ一つ提案があるんだけど、ホームページのテストモニアルからFバームを外した方がいいよ。これが原因で悪いリストに載るファイアウォールインテルプロバイダーがいろいろあるから。これを学ぶのはだいたい辛い方法だよ :/

└

優しいメッセージありがとう！いい提案だね。ずっと更新しようと思ってたんだ。

動的なサインインプロバイダーのURLに対応してる？私たちにとっての大きな決め手（フェデレーテッドサインイン/サインアウトが面倒なのも含めて）は、特定の顧客が自分たちのサーバーに向けたサブドメインを指すセキュリティ要件を持っていることなんだ。だから、サインインリダイレクトをどこに持っていくべきかを判断するためのロジックを使える必要があるんだ。

└

うん。SSOプラグインをチェックしてみて。これを使えば、設定をDBに保存して動的に取得できるよ。

私たちの開発者の一人が君たちを評価してすごく気に入ってたし、私もそうなんだけど、君たちにはSCIMサポートがないから、移行を正当化するのが本当に難しいんだ。私たちは、認証のオーバーホールの一環として「SCIMが手に入る」とプロダクトチームに言う方が簡単だから、ある意味劣った製品に移行したんだ。エンタープライズ顧客を狙うなら、エンタープライズ機能セットをしっかり固めることをお勧めするよ〜でも、いいニュースは、私たちの開発者が君たちのモデルを一番気に入ってるから、機能を拡張するのは君たちの仕事次第だよ！

└

同じく、scimのせいでパスしました。

製品は洗練されているように見えます。3つ質問があります：1. SupabaseをDBとして使っている場合、Supabaseの認証を使うべきですか、それともデータ保存にSupabase DBを使うBetter Authを使うべきですか？2. Supabaseの認証を使うと、auth.usersテーブルへのアクセスができず、国などの追加ユーザー詳細を保存するためには別のprofilesテーブルが必要です。Better Authを使った場合、追加の詳細を保存するアプローチはどうすればいいですか？3. Better AuthのインフラはClerkやSupabaseの認証とどう違うのですか？

└
  1. RLSが必要かどうかによります。Better AuthとSupabaseのRLSの連携を改善するために彼らと協力して取り組んでいますが、もしRLSに依存しないならBetter Authを選んだ方がいいと思います。もっと多機能で、データベースよりもバックエンドとより統合された感じがします。それに、もし将来的にデータベースプロバイダーを変更したくなった場合もできますし。2. そうですね、Better Authに移行して、ユーザーテーブルをメインスキーマに移動する必要があります。Supabase用の移行ガイドがありますよ。3. それはフレームワークの上に構築された追加機能であって、サードパーティの認証サービスではありません。フレームワークはそのまま使い、必要な機能があればインフラに接続して有効にできます。