こんにちは！IT/DEV事業部でUI/UXデザインからエンジニアリングを行っているSakataです！

今回は自社サービスの認証を作成する際に、認証系のライブラリやサービスについてを検討したので、そのメモを残しておきます。

BetterAuthとは？

BetterAuth

BetterAuthは、比較的最近にVersion1.0が公開されたTypeScriptファーストの認証フレームワークです。

類似のサービスには、Auth.js FirebaseAuth Auth0 Supabaseなどがありますが、その中でもBetterAuthはライブラリ形式であるため、ユーザーデータについては自分のDBに保存されることになります。

Next.js界隈だと人気のAuth.js(NextAuth.js)との対抗馬という感じですね

基本的な認証基盤は揃っており
Email/Password、ソーシャルログイン、パスキー、2FA Email OTPなどが一通り揃っており、連携できるSIGN-ONも非常に豊富にあります！

BetterAuthはフレーム非依存

BetterAuhtはTypeScriptでできているもののためフレームワークに依存せずに導入することが可能です。

Nuxt Vue React

バックエンドではHono Expressなどどこでも使えるのが非常に魅力です。

TypeScriptファーストのため型推論も非常に強力で型駆動開発を行う場合にも非常に相性が良いライブラリに思います。

ORM関連では、Drizzle ORM Prismaなどの主要なORMもサポートされているため、バックエンドの構成と同じ技術基盤で扱うことができるのも嬉しいですね。

弊社では、バックエンドにはHono Drizzle PostgresSQLなどを採用しているため、この点の親和性が完璧でとても嬉しいです。

ただし、他の認証基盤とは異なり基本はライブラリでありフルマネージドではありません。

実際のDBやインフラ部分、ログインや登録などのUI部分などその多くは自前で用意をする必要があります。

他の認証基盤との比較

認証基盤を検討した際に、他の認証基盤についても悩んでいました。

特に複雑なアカウント管理の構造に対して対応できるのかどうかに着目しつつ、ランニング費用などとの比較を行なっています。

今回比較の対象にしていたものは、Amazon Cognito / Clerk / Auth0です。

まず、Auth0については費用の面で断念。これがフルマネージドとして機能なども豊富でとても良いと思っていたのですが、サービス初期に入れるにはコスト面と学習コスト面で断念しました。

なので、残るCognitoとClerkとの比較を今回はメインに行います。

まず、BetterAuthは基本的にはOSSのライブラリであるため、　これを使用する分には完全に無料です。

実質かかるのはインフラ部分のランニングコストのみとなります。

BetterAuthに有料のダッシュボード機能もありますが、そこまで機能が多いわけではなく、モニタリングなどは自前で構築をする前提のため、有料部分は一切使用せずにライブラリとして活用を行います。

そのためアプリ組み込みの完全にライブラリとして提供がされているものになります。

ClerkはフルマネージドのSaaS

Clerk

無料枠はありつつも、基本は有料です。

ReactやNext.jsでアプリケーションを作る際にとても人気のあるIDaaSですね！

フルマネージドになるため、BetterAuthと異なり、ユーザーの認証データなどはすべてClerk側に保存されます。

この点でベンダーロックインが発生します。

その上、サービス側で「誰が」を管理するためには自社側のDBにもユーザーデータを保存する必要があります。

この辺りの値段とベンダー依存になるところを許容することができるのであれば、最速で全てを準備するのが完了させることができそうなのが魅力ですね。

基本的なプランは

- 無料プラン　月間10,000MAUまで無料

- 有料プラン ベース料金+MAUに応じた従量課金

となり、ユーザー数が増えれば増えるほどコストが高くなる構造になります。

（とはいえ10,000MAUもあれば当分無料で使えそうではあります）

必要な機能や画面などがそのまま揃っているため、MVPで構築をしたい場合、とにかく早く出して検証をしたい場合などには採用する価値が大いにありそうです！

Auth0は完成度が高い圧倒的な採用と信頼のある認証サービス

Auth0

Auth0はあらゆるところで使われていることから、その機能は非常に豊富で高度なセキュリティ要件や費用についてを賄えることができるのであればやはり採用の検討を行なっておきたいものになります。

基本的にはログインの認証をする場合にはフロントからAuth0を呼び出し認証を行うという手順になりますね。

エンタープライズ向けの機能も豊富に揃っており、最初から利用ユーザー数が多い、エンタープライズ向けのセキュリティ要件のある場合には、基本はAuth0の採用が最初に候補に上がってきそうです。

ただしその分コストは非常に高く、toCかtoBかによっても利用料金が変わってきます。

ここはお財布に非常に余裕のあるサービスだけが採用検討ができるという部分になりますね。

CognitoはAWSとの親和性が高い、そして一番安い

Cognito

Cognitoはその名の通りに、AWSの認証・認可を行えるフルマネージドのサービスです。

AWSのサービスなので、各種AWSサービスとの親和性が非常に高く、シームレスかつセキュアに連携させることができるのが魅力です。

コストパフォーマンスにも非常に優れており
月間 50,000MAUまでが無料で、それを超えても1ユーザーあたり0.6円程度しかかからないのがとてもお財布に優しいですね。

そもそもがAWSに載っているサービスになるため、耐障害性やコンプライアンス対応がしやすいのも魅力でありそうです。

ただし、Cognitoでよく聞く話は開発者体験（DX）が悪いという話です。

AWS特有の概念やポリシーの理解がどうしても発生するため、扱うにはAWSインフラの知識をしっかりと持っておく必要がありそう。

また、こちらもベンダーロックインがあり、他のサービスに移行したいとなった場合にかなり苦労しそうな気配があります。

ただし、AWSとの親和性が高い、Lambdaとの連携などがしやすいというAWS環境のみで閉じる場合には以前有用な選択肢となってきそうです。

今回はBetterAuthを使用することに決めた

まとめると

- 課金が専用で発生しない、独自構築ができ、TypeScript環境との相性がいいBetterAuth

- とにかく爆速で認証基盤を用意することができるClerk

- AWSとの親和性が高く費用も安いCognito

という感じになりそうです。

最終的にClerkかBetterAuthかで悩んでいました。

TypeScriptやNext.jsを使っているためClerkの親和性はとても高いのですが、認証や認可はバックエンド側に閉じることを前提として考えているため、その点でClerkは不採用としました。

特に速度や初期構築の速さは非常に魅力だったのですが、技術構成とアカウント周りの設計の都合で独自構築ができる方が良いと判断し、今回は採用を見送ることにしました。

技術構成として採用の検討が発生しそうなものはBetterAuthかCognitoとなりました。

AWSについては、Cognito自体の設定や構築がかなり面倒くさそうなので、最初期に速度よく開発を進めたいというDXの部分で今はまだ時期が早いとして採用を見送りました、ここの観点はAuth0なども同じです。

なので、開発体験の良さや柔軟性の高さから独自構築が必要なものの、認証・認可周りだけを任せることができるBetterAuthを今回採用するに至りました。

認証や認可の部分をフルスクラッチをすることはセキュリティ的にも厳しく、そもそも実装するべきこと、考慮しておかないといけないところが多すぎるためやはりなるべく何かに乗っかりたいという気持ちが強いです。

ここら辺の採用基準はサービスの規模や要件によっても変わってきそうなため、今回はBetterAuthを採用するに至りましたが、別のところでは他のサービスについても改めて検討を行いたいと思います！

特に個人プロダクトを作る場合にはClerk一択だなと今回思ったので、そういったところでまずは使ってみようと思います！

今回は採用検討に終わったため、またどこかでBetterAuthに詳しくなったタイミングで使ってみた感想を残しておきたいと思います。