Ovlt: セルフホスト向けの軽量でRust搭載の認証サーバー

認証と認可のインフラストラクチャは、システムの最も重要でありながら、最も煩雑な部分であることが多いです。マネージドプラットフォームの重いオーバーヘッドや、JVMベースのソリューションの複雑さを避けたいチームにとって、軽量で安全、かつセルフホスト可能な代替手段を見つけることは容易ではありません。

Ovltは、「プラットフォームの肥大化」を伴わずに、プロフェッショナルグレードの認証インフラストラクチャを提供するために設計された、セルフホスト型のOAuth2およびOIDCサーバーです。完全にRustで構築されており、高いパフォーマンス、厳格なテナント分離、そして最小限のリソースフットプリント（多くの場合、わずか20MBのRAMで動作）に焦点を当てています。

コアアーキテクチャと主な機能

Ovltは単一のRustバイナリとして提供され、現代的な認証に不可欠なコンポーネント、すなわちOAuth2、ユーザー管理、マルチテナンシー、および多要素認証（MFA）を集約しています。

PostgreSQL RLSによるテナント分離

Ovltにおける最も重要なアーキテクチャ上の選択の一つは、マルチテナンシーの扱い方です。データのフィルタリングをアプリケーションレベルのロジックのみに頼るのではなく、Ovltは**PostgreSQL Row-Level Security (RLS)**を活用しています。

このモデルでは、すべてのリクエストがテナントコンテキストを解決し、その後テナントスコープのトランザクションを開始します。データベース自体が境界を強制するため、クエリが実行される前に、他のテナントの行がアプリケーションコードから見えないようになります。これにより、テナント間のデータ漏洩のリスクが大幅に軽減され、セキュリティ境界をデータレイヤーに移動させることができます。

セキュリティと「監査対応」の暗号化

セキュリティ監査やCTOの懸念に対処するため、Ovltはhefestoクレートを使用して、ダブルエンベロープ暗号化戦略を採用しています。メールアドレス、TOTPシークレット、SMTPパスワードなどの機密フィールドは、データベースに書き込まれる前にAES-256-GCM暗号化で保護されます。

文書化されたキー階層と透明な暗号化レイヤーを利用することで、Ovltはセキュリティチームが、データが保存時にどのように暗号化されるかという正確なメカニズムを監査できるようにします。この「ゼロ知識」アプローチにより、データベースが侵害されたとしても、機密フィールドは封印されたままとなります。

TUIによる管理

複雑なWebベースの管理コンソールを必要とする多くの認証サーバーとは異なり、Ovltは**Terminal User Interface (TUI)**を提供します。このTUIは、認証サーバーのライフサイクル全体を管理するために使用されます。具体的には以下の通りです：

• テナントおよびユーザーの作成
• クライアントおよびロールの管理
• Passkeyおよびセッションの設定
• テナントごとのSMTP設定およびGoogle/GitHub IdP統合
• 監査ログ

パフォーマンスとリソース効率

Ovltは、従来の認証プロバイダーに代わる、より軽量な選択肢として位置付けられています。JVM、Redis、およびさまざまなサイドカープロセスを避けることで、ブラウザのタブ1つよりも小さいメモリフットプリントを実現しています。これにより、エッジデプロイメントや、1MBのRAMも惜しいリソース制約のある環境での利用に最適です。

オープンソースとコミュニティ

OvltはELv2ライセンスの下でソースが公開されており、パブリックに構築されています。プロジェクトはコミュニティの貢献を奨励しており、ロードマップは公開されており、開発者がプロジェクトがどこを目指しているのかを正確に把握できるようにしています。

コミュニティからは、Kanidmのような他の軽量なアイデンティティマネージャーとの比較が提案されていますが、開発者はオープンなロードマップとユーザーフィードバックに基づいた反復的な開発に注力しています。