Better Auth、認証の実装差分をTypeScriptのplugin基盤へ閉じ込めるOSS設計

現在、Better AuthはTypeScript向けのauthentication frameworkとして、coreに加えてpluginとadapterを公開している。出典

認証をアプリの外へ追い出さない

Bereket EngidaはBetter AuthのauthorとしてGitHubプロフィールに記載されており、リポジトリは「The most comprehensive authentication framework」と掲げる。出典

provider差分をframeworkで吸収する

従来、OAuth、session、database adapterはアプリごとに実装差分が生まれやすかった。

Better Authはinstallationとconceptsを公式docsにまとめ、実装者が自分のruntimeへ組み込める形にした。出典

pluginを成長の単位にする

認証coreを巨大化させる代わりに、pluginとして機能を増やす。

これにより最小構成で始める利用者と、organizationなどを必要とする利用者を同じ基盤で扱える。出典

OSSの強さと責任

GitHub releasesとcontributorsが継続的に公開される一方、security更新や本番運用を誰が担うかは導入チームの責任になる。出典

Better Authの示唆は、認証を外部SaaSへ丸投げするか自作するかの二択を、拡張可能なframeworkで埋めることにある。

Better AuthのPMFは、認証を自作したいがprovider固有SDKの差分やsession管理を抱えたくないTypeScript開発者にある。

公式docsはinstallation、OAuth、session、pluginを一つのframeworkとして整理している。出典

OSSでadapterとpluginを選べるため、managed authへ全面依存せずアプリ側のデータモデルを保てる点が刺さる。

導入の自由度と実装の統一を同時に求めるチーム向けだ。出典

最大のmoatは、認証core・plugin・adapter・docsが同じTypeScriptの開発体験で積み上がることだ。

単一機能のSDKより移行コストが高まりやすいが、ecosystemの規模は要確認である。

ネットワーク効果は弱〜中程度。

利用者同士が直接つながるサービスではないが、adapter、plugin、issue、docsの蓄積が次の利用者の導入コストを下げる。

対象はTypeScriptでweb applicationを作る小〜中規模チーム、既存DBとsessionを自分で管理したい開発者である。

完全managedの運用委任やSLAを最優先するenterpriseには、導入前の要確認事項が多い。

第一は、認証の共通部分をcoreへ寄せ、OAuthやorganizationなどをpluginとして拡張できる構造だ。出典

第二は、公式docsとGitHubを中心に、実装可能なコードを先に見せるdeveloper-ledな導線である。出典

OSS認証はsecurity更新、adapter互換性、breaking change対応を利用者側も負う。

公開情報だけでは商用supportやSLAの範囲は要確認だ。

また、managed authと比べるとhosting・監視・秘密情報管理の責任がアプリチームへ残る。

自由度がそのまま運用負荷になる。

GitHub repositoryと公式docsを入口にしたdeveloper-led growthが中心だ。

installationからplugin、releaseへ進む導線は、検索で課題を持つ開発者をそのまま利用者へ変換する。

この戦略は広告費を抑えられる一方、security品質とmaintenance速度が成長の上限になる。

主要チャネル: github, documentation, community, content

認証のような横断機能では、単なるAPIラッパーよりcoreとpluginの境界が製品体験を決める。

OSSでは「無料」を価値の中心にするより、既存のTypeScript codebaseへ自然に入るadapterとdocsを整える方が継続利用につながる。

日本向けには、国内B2B SaaSで頻出する組織・権限・監査ログの実装例を日本語docsで厚くすると差別化になる。

ただし個人情報保護法対応やSLAをOSSだけで保証できるとは限らず、法務・運用設計は別途必要だ。