Auth.jsがBetter Authの一部に

 (better-auth.com)
6 ポイント 投稿者 GN⁺ 2025-09-28 | 5件のコメント | WhatsAppで共有
  • Auth.js（旧称: NextAuth.js） は今後、Better Authチームによって保守・管理される
  • Auth.jsはJavaScriptエコシステムで最も広く使われているオープンソース認証ライブラリの1つで、多くの著名なWebサイトで活用されている
  • これまでは認証やセッション管理を自前で実装するのが難しく、どの現場でも同じ基本要素を繰り返し開発する非効率さがあった
  • Better AuthチームがAuth.jsの限界を認識し、将来のビジョンを共有したことで、両プロジェクトは統合してエコシステムをさらに発展させる計画
  • 既存ユーザーは今後もセキュリティパッチなどの保守を受けられ、新規プロジェクトではBetter Authの利用が推奨される

紹介と発表

  • Auth.js（以前はNextAuth.jsとして知られていた） は今後、Better Authチームによって正式に保守・管理される
  • Auth.jsはJavaScriptエコシステムで最もよく知られたオープンソース認証ライブラリの1つで、すでに多くのサービス（ChatGPT、Google Labs、Cal.com など）で使われている

従来のAuth.jsの役割と限界

  • Better Authに統合される前、Auth.jsは開発者がOAuth統合やセッション管理に長時間を費やさずに認証機能を持てるようにしていた
  • しかし、Webアプリケーションが複雑化し、認証要件が多様化するにつれて、基本機能の繰り返し開発や拡張性不足といった限界が目立つようになった
  • 既存チームもこうした点を認識していたが、さまざまな理由から根本的な改善までは実行できなかった

Better Authとの統合の背景

  • Better Authの目標は、さまざまなサービスで認証の主導権を強化することであり、Auth.jsチームとのビジョンも似ていた
  • 内部で議論を重ねる中で、2つのプロジェクトが1つになることが最善だと気づいた
  • 現在のAuth.jsが無数のアプリケーション、企業、開発者にとって重要であることを踏まえ、継続的なセキュリティパッチと緊急課題への対応を約束している

推奨事項とエコシステム発展戦略

  • 既存でAuth.js（NextAuth.js）を使っているプロジェクトは、今後も引き続き問題なく利用できる
  • 新規プロジェクトでは、特定の機能（代表的にはデータベース不要のstateless session管理）が必要でない限り、Better Authの利用を推奨する
  • Better Authのロードマップには、これらの機能も追加予定となっている。重複開発の代わりに、エコシステムを1つに統合して、より発展的な方向を目指す

マイグレーションとコミュニティへの感謝

  • マイグレーションを検討しているチームにはガイドを提供し、今後さらに多くのドキュメントや資料を追加する予定
  • これまでAuth.jsを発展させてきたコミュニティと主要な貢献者たち（特に Balázs、Thang Vu、Nico Domino、Lluis Agusti、Falco Winkler）に深い感謝を伝えている
  • Better Authの出発点がAuth.jsであり、両プロジェクトの統合によって認証エコシステムがさらに前進できることを強調している
  • 基本目標は変わらず、「認証の主導権は開発者自身にある」という考えを掲げている

関連記事

5件のコメント

 
shakespeares 2025-10-05

Next.js界隈の変化が激しすぎて、かなり疲れます…
 
ahwjdekf 2025-09-28

こんなに不安定なものを使うくらいなら、いっそ clerk みたいなものを使って、ユーザーが増えてきたらそのときに本格的に認証の問題を考えるほうがよさそうですね
 
ahwjdekf 2025-09-28

少し前に auth.js で何か作ってみたんですが、その間にまたいろいろ変わりましたね。Web 周りは本当にややこしくて疲れます。あと、ドキュメントとサンプルに間違いがあったので PR も出してみたんですが、特に問題ないというような感じで閉じられてしまって、かなり面食らいました。内部的にチームがうまく回っていない状態だったように思います。
 
GN⁺ 2025-09-28
Hacker Newsの意見

  • Better Authが500万ドルの資金調達を実施、完全無料のプロジェクトが商業ベンチャーに取り込まれる流れは残念に感じる

    • Auth.jsとNextAuth.jsの状況はあまり健全ではなかった。NextAuth.js v5の開発は2023年5月に始まったが、ずっとベータのままだった。2023年8月にAuth.jsへ改名され、10月にv5.0.0-beta.0が公開された。主要コントリビューターのBalázs Orbánは2025年1月にチームを離れ、結局いまだに安定版なしでベータのままになっている。 変遷, 議論, 改名の記録, ベータ公開, コミット履歴, X(Twitter)での発表を参照
    • こうした懸念は理解できるが、Auth.jsはむしろ「本当に無料」だったとは思わない。多くの企業から支援を受けており、Clerkもドキュメントサイトに広告を出していたほどだ。Better Authは当初、商業目的なしのオープンソースプロジェクトとして始まったが、より多くの企業が簡単に認証システムを自前で持てるようにしたいという思いから、商業的な拡張が自然に進んだ。Auth.jsを引き受けた理由も、チームがプロジェクトから手を引くことになり、放置されるのを防ぐためだった。Luciaのようにオープンソース認証が信頼を失った例もすでにあり、実際に放置されて信頼が崩れる状況を避けたかった
    • Auth.jsは完全無料ではあるが、事実上放置された状態になっている
    • 私はFusionAuthで働いており、NextAuthを支援したことがある。人は生活していかなければならないし、NextAuthもスポンサーの商業的支援を受けたプロジェクトだった。実際にスポンサー資金がどれほど多かったのかは正確には分からないが、ClerkやVercelがプロジェクトに影響を与えた件など、関連する意見を見ておくとよい。オープンソースのビジネスモデルの難しさについては個人ブログにより詳しく書いてあるので参考までに
    • 今回のケースでは、少なくとも調達した資金は、オープンソースプロジェクトを基盤にした将来のSaaS認証ソリューション開発に向けられているようだ

  • ChatGPT、Google Labs、Cal.comなどでAuth.jsが実際に使われていると聞いた。ただ、OpenAIがAuth0から認証システムを移したのは見ていないので、何があったのか気になる

    • 特に知っている話はないが、私の経験ではAuth0への移行を試みたことがあり、あまり良くなかった。少しでも標準から外れるとサポートがかなり弱くなり、正常に動いていてもそれほど良くない。それでも認証をサードパーティSaaSに外注するなら、Auth0がまだ比較的ましな選択肢かもしれない
    • OpenAIの実例は、Ory公式ケーススタディから一部推測できる
    • AWS CognitoとAuth0で迷っている。実際のところ、CognitoとAuth0のどちらがより良いと感じるのか、いろいろな人の体験談を聞いてみたい
    • OpenAIはSSO/SAMLをWorkOSへ移し、一般消費者向け認証はオープンソースをforkして使っているようだ
    • Oryも自社がOpenAIで使われていると主張しているので、おそらくOpenAIはOryのサービスとBetter Authなどを組み合わせてソリューションを構築したのだろう

  • このフレームワークのおかげで認証処理をほとんど気にしなくていいほど簡単になった。設定も簡単で、各フレームワーク間でも使い方が一貫している。今後もこうした利点が続きそうで安心した

  • 誰かがBetter Authは「auth.jsより良いのか？」と聞いたとき、とっさに「auth.jsよりは良い」と思ったが、結局そういうことになった

  • Go言語にもこういう手軽な認証ソリューションがあればいいのに

    • 自分でGo、JS、Rust（サーバーサイドWASM活用）まで対応するソリューションを作っている。今後はPythonなども対応予定で、BetterAuth/OpenAuthほどの完成度や機能はないが、プロジェクトで認証が必要なときの開発体験（DX）はかなり満足している。 decent-auth GitHub
    • 私もまったく同感だ。golang向けの認証ソリューションがないわけではないが（FusionAuthのように）、RailsのdeviseやDjangoのユーザーモデルのように、アプリに直接溶け込むフレームワークレベルで簡単なライブラリを求めているのだと思う。この話題に関するredditスレッドでは複数の代替案も紹介されているので、参考になる
    • authelia/authelia GitHubも試す価値がある
    • ory/kratos GitHubも有望だ

  • 両方の製品を使ったことがあり、個人的には満足していた。2つのプロジェクトが協力することになってうれしい

    • 実際のところ、Better AuthはAuth.jsを維持するふりをしながら、人々をBetter Authへ誘導しようとしているだけだ

  • Clerkを使ってみているが、悪くなさそうだ。何にでもうわさはあるが、私はひとまず開発に集中したい

    • Clerkはまだ試していないが、お金を払うことで実際に開発が楽になるなら、特定のプロジェクトには合っているかもしれない。ちなみにBetter Authは、私のbare-bonesリポジトリでも1時間もかからずセットアップが終わった

  • 開発者の立場からすると、単純さを最大化してくれるのでBetter Authのほうが単純に良いと感じる

  • この知らせは残念だ。事実上、Auth.jsの追加開発が止まるように見える。私はAuth.jsのシンプルな関数実装だけでGraphQL APIのバックエンドで完璧に使えていたのが気に入っていたが、Better Authはデータ型がプラグインごとに異なり、TypeScriptのanyのように一般化されすぎている。さらに、データベーススキーマ設計やマイグレーション実行の責任までプラグイン開発者に委ねられている。認証ライブラリとしてはやりすぎだと思うし、この構造は好きになれない。アダプターを別途作ることもできるが、そのインターフェースですら、一般的すぎるSQL-likeな任意クエリ実行器を実装しなければならず、スキーマへの直接的な統制権が失われる。マイグレーションも単にコード文字列を受け取ってevalする構造なので、セキュリティ面の統制も容易ではない。 以前からBetter Authは技術的な斬新さよりも、開発者が独学だとか若いといった点に注目が集まる雰囲気があり、偏見を持たないようにしていたが、こうした懸念もまったくの的外れではなかったように思う。それでもAuth.jsが放置されている現状よりはましだが、JSエコシステムのオープンソース認証ライブラリの状況がそれだけ残念だということだ。 adapter実装例, TechCrunchで紹介された開発者記事

      1. Auth.jsを完全終了するのは、既存ユーザーが問題なくBetter Authへ移行できると確信できたときだけだ（つまり、まだかなり先の話だ）。実際には、全員が強制的に移行しなければならない状況にはならない可能性が高い。
      2. プラグインによる追加機能はNextAuthにはなかったものだ。コアライブラリだけでもNextAuthのほぼ大半の機能を提供しており、ほとんどのプラグインは私たちが直接提供している。望むなら自分でプラグインを書くことも、コピーして修正することも、私たちが提供するプラグインだけを使うこともできる。DB処理はこちらで面倒を見るので、認証システムを自前で持ちながらも、自分でロジックを書く必要はない。
      3. Auth.jsはすでにかなり前から非活性状態だった。突然の終了はオープンソース認証エコシステムへの信頼に致命的なので、それを防ぐためにBetter Authへ引き取った。Lucia Authのときにも経験した信頼喪失の問題を意識している

  • Better Authの発表から3時間後、Vercelに関する告知をGitHubコミットで削除した