Auth Stackの開発者たちはAuth0をやめていて

マネージドアイデンティティは、請求書が届くまでの短絡的な解決策のように思えます。Auth0やOktaのようなサービスは月間アクティブユーザー数に基づいて課金しますので、ユーザー数が10,000から100,000に急増すると、認証コストが月々数百ドルから数万ドルに跳ね上がる可能性があります。スパイキーなトラフィックを持つB2Cアプリにとって、そのMAUメーターは成長に対する税金となり、予測可能な項目ではなくなります。

ベンダーロックインは痛みを増幅させます。一度、自社のルールエンジンにログインフロー、ルール、ユーザーメタデータを組み込むと、移行は開心術のようになります。カスタムアクション、独自のトークン、ホストされたログインページはすべて、チームがコアの認証ロジックをリファクタリングするのではなく、支払いを続けるように促します。

厳密に管理されたエコシステムは安全性を約束しますが、しばしば柔軟性を欠いています。多くのプロバイダーは、ホストされたユーザーインターフェース、SDK、そして独自の流れに強制的に従わせ、単純なカスタマイズでさえ（例えば、新しい認証ステップの追加や特殊なレガシーSSOのサポートなど）プラットフォームと戦っているように感じさせます。標準外のログインプロセスが必要になると、自分が実際に持っている余地がどれほど少ないかを実感します。

データの所有権は、さらに不快な層を追加します。ユーザーのID、セッション、監査ログは他人のクラウドにあり、不透明な内部ポリシーやレート制限によって管理されています。エクスポートAPIは存在しますが、スキーマやインデックス、データが実際にバックアップにどのくらいの期間保存されるかについて、低レベルの制御を提供することはほとんどありません。

規制された業界のスタートアップにとって、これらの制約はすぐに現実と衝突します。EU、ヘルスケア、またはフィンテックにおける厳格なデータ居住地ルールは、ユーザーテーブルが特定の地域や特定のデータベースクラスタに存在することを要求します。プロバイダーの返答が「我々のロードマップ」や企業専用地域である場合、コンプライアンスチームは、なぜ認証が外注されているのかを問い始めます。

開発者たちは、より多くのコントロール、より多くの透明性、そして全体のスタックを所有する能力を要求しています。Ory Kratosのようなオープンソースシステムはモデルをひっくり返します。自分自身でアイデンティティサーバーを運営し、自分のスキーマを定義し、ユーザーデータを自分のデータベースに保持します。マネージド認証もまだ役割がありますが、金の手錠はますますきつく感じられるようになっています。

管理された認証プラットフォームは、あなたのすべてになりたがります。Ory Kratos は、あなたのアイデンティティエンジンでありたいだけです。それは、あなたが使うUI、フレームワーク、デバイス—Next.js、モバイル、SPA、さらにはレガシーなモノリスでさえ—の背後に置かれるAPIファースト、バックエンド専用のアイデンティティサーバーとして提供され、独自のウィジェットやダッシュボードに縛り付けることはありません。

Kratosは、登録、ログイン、プロフィール管理、復旧、設定など、すべての主要な認証操作をHTTP APIを通じて提供します。フロントエンドはパスワードのロジックを保存したり、マジックリンクを作成したりする必要はなく、Kratosが定義し確保するフローを調整するだけです。この分離により、認証は他の内部マイクロサービスのように感じられ、ブラックボックスのSaaS製品ではなくなります。

ボックスから出すと、Kratosはほとんどのアプリが悪化させて再構築するコアフローを処理します。ユーザー登録にはスキーマに基づく検証、パスワードによるログイン、および高リスクアカウント向けのオプションの多要素認証（MFA）が含まれています。また、メール確認、アカウントの有効化、セッションの管理（セッションの取り消しやローテーションを含む）も行います。

フローは、設定によって制御されるステートマシンのように動作します。ユーザーが登録後にどこに移動するか、どのフィールドを必ず入力させるか、リカバリーや確認リンクがどのように動作するかを定義できます。ほとんどのアプリにとって、これは「パスワードを忘れた場合」や「メールを確認する」または「プロフィールを更新する」ためのカスタムグルーコードを、UIを接続する以外は必要としないことを意味します。

設計上の自己ホスティングにより、KratosはDockerが動作する場所ならどこでも実行できます：ノートパソコン、Kubernetesクラスター、またはクローゼット内のベアメタルボックス。公式のクイックスタートは単一の `docker-compose` ファイルを使用していますが、同じコンテナイメージはマルチノード展開にもスケールします。地域ロックなし、強制移行パスなし、不明瞭なメンテナンスウィンドウなし。

ストレージはあなたの手の中にあります。Kratosはローカル開発用にSQLite、運用用にPostgreSQLをサポートし、YAML設定のシンプルなDSNを介して接続します。ユーザーテーブル、監査証跡、およびバックアップはあなたのものであり、これはGDPR、SOC 2、ならびに「私のデータは正確にどこに保管されていますか？」と尋ねる顧客にとって重要です。

セルフホスティングは、MAUベースの価格に関する不安を解消します。ユーザー数が急増するたびにAuth0やOktaに支払うのではなく、CPU、RAM、ディスクに対して支払います。後でソーシャルログイン、OAuth2、または高度な権限が必要になった場合でも、Kratosはプラットフォームの書き換えを強いることなく、より広いOryスタックに組み込むことができます。

マネージドアイデンティティは、デプロイメントにズームインすると異なって見え始めます。Ory Kratos は、どこにでも展開できるDockerネイティブサービスとして提供されます—あなたのKubernetesクラスター、ベアメタルボックス、または安価なVPSなどです。一方、Auth0は主に完全に管理されたSaaSとして存在し、そのインフラストラクチャ、スケーリング、アップグレードはダッシュボードとAPIの背後に抽象化されています。

制御が必要なとき、その分離は重要です。Kratosでは、あなたの認証スタックはネットワークの境界内にあり、アプリやデータベースの隣に配置され、既存の可観測性やCI/CDに接続されています。Auth0は洗練されたクラウドコンソールとサービスレベル契約（SLA）を提供しますが、その代わりにリージョンやロールアウトのペース、そして不透明なパフォーマンス調整を受け入れることになります。

コストモデルも同様に大きく異なります。Auth0は月間アクティブユーザーに基づいて価格を設定し、機能やテナントをサブスクリプションのティアごとに制限しており、サインアップが急増したり、一時的に非アクティブユーザーが戻ったりすると価格が急上昇することがあります。Kratosはオープンソースで、アイデンティティごとの料金ではなく、コンピュート、ストレージ、オペレーション時間に対して支払いを行います。

スパイキーなトラフィックや季節的なトラフィックを持つ製品、例えばゲームの発売、チケット販売プラットフォーム、試験シーズンに合わせた教育ツールなどでは、MAU課金がボラティリティ税に変わります。自己ホスト型のKratosクラスターは、最小限のリソースで静かに稼働し、必要に応じて水平スケールすることができ、ユーザーの行動に結びついた驚きの請求書が発生することはありません。予測可能なインフラ料金を予測不可能なSaaS料金と交換することになります。

柔軟性は、KratosがそのAPIファースト設計に最も力を入れている部分です。登録、ログイン、回復、確認、多要素認証（MFA）など、すべてのフローはJSON APIを公開しており、これらはNext.jsのSPA、ネイティブモバイルアプリ、またはCLIなど、どんなクライアントからでも呼び出すことができます。アイデンティティスキーマは設定に保存されているため、プロバイダーがあなたのユースケースを承認するのを待つことなく、会社ID、カスタムロール、地域フラグなどの特性を定義できます。

Auth0は膨大な数の事前構築された統合やルールを提供していますが、それには制約があります。彼らの「ユニバーサルログイン」ページ、アクショントリガー、テナントモデルに接続します。深く非標準のフロー—プログレッシブプロファイリング、カスタムルーティングを伴うマルチテナントB2B、または複雑な組織別ポリシー—は、しばしば回避策や脆弱な接続コードを必要とします。

Kratosはモジュールスタックに組み込まれます：OAuth2/OIDCにはHydraを、権限管理にはKetoを、アイデンティティ対応プロキシにはOathkeeperを、ドロップインUIコンポーネントにはOry Elementsを組み合わせてください。Auth0はこれらの多くの機能を一つのブランドの下にまとめていますが、そのバンドルはベンダーロックインを強化するものでもあります。自分たちのインフラを所有することに意欲的なチームにとっては、Ory Kratos - ドキュメントは製品マーケティングのようではなく、実際に制御できる認証システムの青写真のように感じられます。

クレイトスは、より大きなものの中心に位置しています。それは、Auth0やOktaが一つの不透明なボックスとして販売しているものを解体しようとするモジュラーOryスタックです。一つのモノリスの代わりに、Oryはアイデンティティを独立して実行、スケーリング、交換できる集中したサービスに分割します。クレイトスはアイデンティティとセッションを扱いますが、トークン、権限、エッジの強制を他のサービスに引き渡します。

OAuth2とOpenID Connectのために、Ory Hydraが登場します。Hydraは認可サーバーとして機能し、OAuth2アクセストークンとOIDC IDトークンを発行します。これらはすでに標準に準拠したクライアントによって理解されています。Kratosをログインプロバイダーとして設定し、Hydraに同意フロー、トークンの有効期限、そしてウェブ、モバイル、機械間通信のワークロードにおけるクライアント登録を管理させることができます。

詳細な認可はOry Ketoから来ており、Google Zanzibarスタイルの関係ベースのアクセス制御を実装しています。アプリロジックにロールをハードコーディングする代わりに、「ユーザーXはドキュメントYを編集できる」といった関係をモデル化し、Ketoに意思決定を求めます。このパターンは、シンプルなRBACから、毎分数千の許可が変更される複雑でマルチテナントなセットアップまでスケールします。

エッジに位置するOry Oathkeeperは、あなたのAPIやサービスの前にあるアイデンティティ認識型プロキシとして機能します。OathkeeperはHydraからトークンを検証し、Kratosからアイデンティティの特性を取得し、最終的なはい/いいえの判断をKetoに委任できるアクセスルールを適用します。ルールはコードではなく設定として定義されているため、アプリを再展開することなくポリシーを更新できます。

それらを組み合わせると、エンタープライズスイートのフルスタック代替として、アイデンティティのためのKratos、OAuth2/OIDCのためのHydra、認可のためのKeto、ゲートキーパーとしてのOathkeeperが得られます。各コンポーネントはコンテナとして動作し、HTTP/JSONを使用し、オープンソースを維持するため、ベアメタル、Kubernetes、または単一のDocker Composeファイル上に展開できます。MAUごとに支払うのではなく、インフラに対して支払い、認証パイプラインのすべての要素を自分の手の中で管理できます。

ゼロからOry Kratosを立ち上げるには、ウェブダッシュボードではなくDockerから始まります。まず、`kratos-demo`フォルダーを作成し、その中に`docker`サブディレクトリを作ります。そして、公式のOry Kratosイメージを引き出し、ローカルの`users.db` SQLiteファイルをマウントし、`config/kratos.yml`および`identity.schema.json`をバインドする`docker-compose.yml`を設定します。その後、`docker compose up`を実行すると、Kratosが開発モードで起動し、ローカルホスト上に公開APIと管理APIを公開します。

`docker-compose.yml` は公式の quickstart.yml を主に反映していますが、ノートパソコン向けに調整されています。このファイルは `KRATOS_PUBLIC_URL` と `KRATOS_BROWSER_URL` をそれぞれ `http://localhost:4433` と `http://localhost:4455` に設定し、設定ディレクトリをマウントし、確認メール用のメールサーバーコンテナをリンクしています。ポートはデフォルトのまま—パブリック用は4433、管理用は4434—なので、ドキュメントからの例示クライアントコードはそのまま動作します。

設定は次に二つのコアファイルに移ります：`kratos.yml` とアイデンティティスキーマJSONです。アイデンティティスキーマは、email-password/identity.schema.jsonからコピーされたもので、`email`、`first_name`、`last_name` などの特性とパスワード資格情報を持つ JSONスキーマ を定義しています。これは、Kratosのコアに触れることなく、カスタムフィールド—会社ID、役割、または機能フラグ—で拡張することができます。

`kratos.yml` ファイルはすべてをまとめる役割を果たします。`selfservice.default_browser_return_url` と許可されたオリジンを、`http://localhost:3000` 上の Next.js アプリにポイントします。また、HTTP メソッドと CORS ヘッダーをホワイトリストに登録します。各フロー—`login`、`registration`、`recovery`、`verification`、`settings`—には、`/auth/login` や `/auth/register` といったフロントエンドのルートに直接マップされる `ui_url` が割り当てられます。

秘密とメール設定は同じYAMLにあります。デモ設定ではプレースホルダーの秘密を使用しますが、本番環境では`secrets.cookie`と`secrets.cipher`の強いキーを回転させる必要があります。SMTP資格情報はメールサーバーを設定し、Kratosが確認および回復リンクを送信できるようにし、その後ユーザーを同じ`ui_url`ルートに戻します。

フロントエンドでは、Next.js アプリが `@ory/nextjs` と Ory Elements を使用して Kratos に接続します。環境変数として `NEXT_PUBLIC_KRATOS_PUBLIC_URL=http://localhost:4433` と `KRATOS_BROWSER_URL=http://localhost:4455` が `.env.local` に設定され、Docker の URL と一致します。小さな `ory.config.ts` が SDK をそれらのエンドポイントに接続します。

Next.jsのミドルウェアは、実行時に重い処理を担当します。`middleware.ts`ファイルはリクエストを interceptし、KratosのセッションAPIを呼び出し、認証されたユーザーを通過させるか、匿名の訪問者をKratosによるログインフローにリダイレクトします。これにより、OktaやAuth0ではなく、あなた自身のスタックで完全に統合された登録、ログイン、メール確認、およびMFA画面を実行できます。

マネージドアイデンティティスタックは通常、フロントエンドで崩壊します。あなたはベンダーのホストされたログインボックスに屈服するか、すべての認証エッジケースに対してフォームの状態、バリデーション、およびエラーハンドリングに数日を費やすことになります。Ory Elementsは、まさにその面倒を解消するために存在します。

単一のウィジェットを配送する代わりに、ElementsはReact、Next.js（アプリルーターを含む）、およびその他の現代的なフレームワーク向けの完全なUIコンポーネントライブラリです。これは他のnpmパッケージと同じようにインストールし、そのコンポーネントをルートに追加し、Ory Kratosの公開エンドポイントを指し示すだけです。

トリック：Elementsは「ログインフォーム」がどのように見えるかをハードコーディングしていません。Kratosは、ログイン、登録、リカバリー、設定、検証の各フローを、フィールド、メソッド、CSRFトークン、メッセージを説明するJSONスキーマとして公開します。Elementsは実行時にそのスキーマを読み取り、自動的に適切なUIをレンダリングします。

デモのNext.jsアプリでログインルートにアクセスすると、ElementsはKratosからログインフローを取得し、フォームを構築します：メールフィールド、パスワードフィールド、送信ボタン、バリデーションメッセージ、さらにアイデンティティスキーマで定義した追加の属性も含まれます。Kratosで多要素認証をオンにするか、ユーザー名フィールドを追加すると、レンダリングされたUIはフロントエンドの書き換えなしで更新されます。

その動的な挙動はフロー全体に適用されます。Elementsはデフォルトで以下の機能を提供できます： - ログインと登録 - アカウント設定とプロフィール管理 - パスワードの復旧とメール確認 - MFA登録とチャレンジ画面

開発者はプレゼンテーションを完全にコントロールできます。コンポーネントはスタイルが施されていないか、軽くスタイルが適用されているため、自分のレイアウトでラップし、TailwindやCSS Modulesを適用し、ロジックを再実装することなくすべての画面にブランドを適用できます。プロトコルの難しい詳細をアウトソースしながら、デザインシステムを維持します。

時間の節約は急速に積み重なります。通常のチームは、認証フォームの構築と調整に1～2週間を費やし、その後、要件が変わるにつれて維持するためにさらに時間をかけます。しかし、Elementsを使えば、そのほとんどは数つのルートと環境変数を設定するだけに簡略化されます。これはBetter Stackのデモでも示されています。

より深いカスタマイズのためには、アイデンティティ特性、フロー、またはセキュリティポリシーを変更することができます。その場合、Kratos自体を調整します。公式のOry Kratos ドキュメントでは、これらのバックエンドの変更がどのように自動的にElementsを利用したUIに反映されるかを説明しています。

セキュリティはOry Kratosの中心にあり、後付けではありません。ボックスから出してすぐに、KratosはすべてのパスワードをHave I Been Pwnedの膨大な漏洩データベースでチェックし、実際の漏洩にすでに現れた認証情報を拒否します。このチェックだけで、パスワードの再使用を利用したアカウント乗っ取りの試みの全クラスが静かに排除されます。

Kratosは、レート制限、セッションの強化、CSRF保護を組み込んでいるため、ミドルウェアで再発明する必要はありません。パスワードポリシー、セッションの有効期間、そして多要素認証は設定にあり、コントローラーやプラグインに散らばることはありません。すべてが同じAPIファーストエンジンを通るため、ウェブ、モバイル、APIクライアント全体で一貫したセキュリティポスチャーを実現できます。

アドホックな「ベストプラクティス」の代わりに、KratosはNIST、IETF、およびMicrosoftやGoogleの主要な研究グループからの指針を追跡します。つまり、現代のハッシュアルゴリズムのサポート、至る所でTLSを優先する輸送セキュリティのデフォルト、恣意的なパスワードの複雑さルールといったアンチパターンを避けるログインフローが含まれます。このプロジェクトのメンテナーは、トロイ・ハントや他の人々の使いやすいセキュリティに関する作業を明示的に引用しており、そのためデフォルトは「安全で人間的」であり、「安全で敵対的」ではありません。

コンプライアンスチームは流行語よりも管理を重視しており、セルフホスティングのKratosはそのために設計されています。ユーザーのアイデンティティ、セッション、監査履歴は、あなた自身のデータベース、あなた自身の地域、あなた自身の保持ルールの下に存在します。クラウド、静的暗号化、バックアップ戦略、そして規制当局に合ったデータ居住地のストーリーを選択できます。ベンダーの共有SaaSクラスタではなく、あなた自身のニーズに合わせて管理します。

GDPRにおいて、そのコントロールは実際の利点に変わります。データ処理契約は、他者の認証サイロの単なるテナントではなく、プロセッサーであるときにシンプルになります。消去権、データのエクスポート、目的制限は、他の第三者へのサポートチケットではなく、自分のスタック内での実装の詳細となります。

Auth0とOktaは同様の基準に合わせて設定できますが、常に彼らのガードレール内で操作する必要があります。一方、Ory Kratosでは、そのガードレールはあなた自身のポリシーであり、コードや設定として表現され、インフラ全体と一緒に監査されます。

マルチファクター認証は通常、SDKやQRコードライブラリ、カスタム設定UIを調整することを意味します。しかし、Ory Kratosを使えば、YAMLファイルでいくつかのフラグを切り替えるだけで、あなたのアプリはまるで経験豊富なセキュリティ製品のようにTOTPを扱えるようになります。KratosはそのAPIを通じて2FAフロー全体を公開しているため、バックエンドはクリーンなままで、フロントエンドは特別なセキュリティ回路が必要ありません。

Kratosの設定でTOTPをオンにすると、サーバーはすぐにアイデンティティフローに新しい「2FA」セクションを追加します。ユーザーがオプトインすると、Kratosはシークレットを生成し、それを`otpauth://` URIとしてエンコードし、レンダリング準備が整ったQRコードペイロードを返します。あなたのアプリはシークレットに直接触れず、Kratosがそれを保存し暗号化します。その後、すべてのログイン時に検証を強制します。

この動画のNext.jsデモでは、Ory Elementsがそのバックエンド機能を完全管理された設定画面に変える様子を示しています。要素コンポーネントを`/settings`ルートにドロップし、それをあなたのKratosパブリックURLに指し示すと、追加のReactステートマシンなしでライブユーザーダッシュボードが得られます。ユーザーは以下のことができます：

• 1プロフィール情報を更新する（メール、名、姓）
• 2パスワードを変更する
• 3TOTPベースの2FAを有効または無効にする

すべてはElementsから事前に構築されたアクセス可能なコンポーネントとして出荷され、型付きフローを使用してKratosと通信します。カスタムフォームをランダムなエンドポイントに接続するのではなく、Kratosがランタイムで定義する宣言的なフォームモデルをレンダリングしています。Kratosがフィールドを追加または変更すると、UIは自動的に更新されます。

2FAの設定中、KratosはユーザーにQRコードのスキャンと最初のコードの確認を案内します。サーバーはTOTPを保存されているシークレットと照合し、時計のズレを処理し、アイデンティティレコードにおいて第二の要素をアクティブとしてマークします。ユーザーが再ログインする際、Kratosは有効なTOTPの後にのみセッションをシングルファクターからマルチファクターにアップグレードし、あなたのアプリは結果のセッション状態を読み取ります。

その関心の分離が重要です。KratosはQR生成、シークレットストレージ、TOTP検証を担当し、Ory ElementsはUXを担当します。あなたのアプリは、数週間ではなく数分で立ち上げられる、安全で完全に管理されたMFAパイプラインをシンプルに利用します。

管理されたアイデンティティプラットフォームはHacker Newsで開発者を失い続けており、Ory Kratosは「これから始めていれば良かった」といった選択肢としてそのスレッドに登場します。コメント投稿者はそのAPIファーストのデザイン、クリーンなHTTPフロー、Dockerが動作する場所ならどこでも実行できる点（5ドルのVPSからKubernetesまで）を一貫して称賛しています。MAUに応じてスケールするAuth0やOktaの見積もりに直面するスタートアップにとって、その魅力は明確です：予測可能なインフラコスト、ユーザーごとの料金なし、将来的に解消しなければならない専有ルールエンジンなし。

Kratosは認証が製品の核心であるときに最適に機能します。マルチテナントのSaaS、プライバシーに敏感なアプリ、または規制対象のワークロードを構築するチームは、アイデンティティデータ、スキーマ、およびライフサイクルを完全に管理できます。データベースを所有し、JSONアイデンティティスキーマを定義し、Ory Elementsや独自のUIを介して、React、Next.js、またはネイティブクライアントへのフローをどのように接続するかを決定します。

理想的なプロジェクトは通常、いくつかの特性を共有しています： - 登録、復旧、および設定フローの深いカスタマイズが必要 - データの居住地、GDPR、または内部監査の要件 - Ory Hydra、Keto、およびOathkeeperを使用して、OAuth2、SSO、および詳細なアクセス権を追加する長期的な計画

そのモジュラーアーキテクチャは、「一つの巨大なアイデンティティ製品」プラットフォームに疲れた開発者を魅了する要素です。最初はメール・パスワードとTOTPから始め、その後でソーシャルログインや企業SSOを追加することができ、すべてを書き直す必要はありません。Ory Documentation Hubはこれを重視し、1つの巨大なセットアップウィザードではなく、各サービスごとの独立したガイドを提供しています。

トレードオフは現実であり、Hacker News のスレッドはそれを曖昧にしません。Kratosを運用するということは、Dockerイメージ、設定、マイグレーション、SMTP、監視、インシデント対応を所有することを意味します。SaaSの請求書を運用の負担に置き換えるのです：Terraformモジュール、CIパイプライン、ログ集約、オンコールのローテーションなど。

エンジニア主導の組織は、これをフェアな取引と見なす傾向があります。すでにPostgreSQL、Redis、そしてサービスメッシュを運用しているなら、もう1つGoサービスを追加することは混乱ではなく、ただの雑音です。しかし、ログイン機能を持つマーケティングサイトを出荷する2人チームにとっては、Auth0の請求書が後で痛い思いをさせるとしても、フルマネージドサービスの方が依然として速いかもしれません。

クレイトスは意識的な選択です。自分のアイデンティティバックボーンを運用することの代償として、ベンダーロックインから自由を手に入れます。そして、増え続ける開発者層にとって、その取引はついに魅力的に映っています。

制御が現代のインフラを定義し、Ory Kratos はアイデンティティに対する制御が実際にどのようなものかを示しています。Auth0やOktaからログインボックスを借りて、次のトラフィックの増加で料金が急騰しないことを祈るのではなく、自分自身のアイデンティティサーバーを運営し、Dockerで出荷し、Next.js、React、Goなど任意のスタックに接続します。認証はもはやブラックボックスではなく、通常のアプリコードに戻ります。

KratosはSaaS依存の構図をひっくり返します。登録、ログイン、復旧、メール検証、MFAを処理するAPIファーストエンジンを提供し、UIやフロントエンドフレームワークに依存しません。OAuth2、細かな権限、またはアイデンティティ対応プロキシが必要ですか？必要なときにHydra、Keto、Oathkeeperを組み込むことができ、全てを一度に購入する必要はありません。

コスト構造も変化します。MAUや機能によって管理された認証費用は、ユーザーが10,000から100,000に急増すると、五桁の驚きに変わることがあります。Kratosはオープンソースですので、主なコストは計算リソース、ストレージ、運用時間となります。また、5ドルのVPSから複数のリージョンにわたるKubernetesまで、何でも自己ホスティングできます。

開発者体験は一流のままです。Ory Elementsは、事前に構築されたReact/Next.jsコンポーネントを提供しますので、ログイン、登録、設定のフローを数週間ではなく数時間で実装できます。クイックスタート用のDocker Composeファイル、サンプルアイデンティティスキーマ、およびNext.jsの例アプリケーションにより、メール確認とTOTPベースの二要素認証を備えた実行可能なスタックを午後の間に構築することができます。

これは単に一つの認証プロバイダーを別のものに置き換えることではなく、誰があなたのアイデンティティレイヤーを所有するかを決定することに関するものです。新しいSaaSを始める、モノリスをリファクタリングする、またはAuth0の料金に驚いている場合は、1日を確保してKratosを設定してください。現在の認証を監査し、価格、ロックイン、エクスポート経路、柔軟性を確認します。それから、次のプロジェクトが他者のロードマップに基づいて行われるべきか、あなた自身のものにすべきかを決めてください。

Ory Kratosとは何ですか？

Ory Kratosは、オープンソースのAPIファーストのアイデンティティおよびユーザー管理サーバーです。登録、ログイン、多要素認証（MFA）、アカウントの復旧などの主要な認証フローを扱い、開発者が自分でホスティングし、認証スタックを完全に制御できるようにします。

Ory Kratosは完全に無料ですか？

はい、Ory Kratosのコアソフトウェアはオープンソースで、自己ホスティングが無料です。また、Oryは有料のエンタープライズライセンスと、追加機能として高可用性、SLA、専用サポートなどを提供するマネージドクラウドサービス（Ory Network）も提供しています。

Ory KratosはAuth0とどのように比較されますか？

Kratosは、自己ホスティングされたオープンソースモデルを通じて、より高い柔軟性、コントロール、そしてコスト効率を提供します。一方、Auth0は完全に管理されたサービスで、迅速なセットアップと広範な事前構築された統合を提供しますが、ベンダーロックインや潜在的に高いコストの問題があります。

既存のユーザーをAuth0からOry Kratosに移行することはできますか？

はい、OryはAuth0などのプラットフォームからKratosへの既存ユーザーベースを移行する方法についてのドキュメントとガイドを提供しており、よりスムーズな移行を可能にしています。