認証モデル

Mezusphere(メズスフェア)はトラフィックがワークロードに到達する前に、エッジでリクエストを認証します。認証はSDKインテグレーションやミドルウェアライブラリではなく、Console(コンソール)からルートごとに有効化するトラフィックレイヤーの機能です。

エッジでの認証適用

ルートで認証が有効な場合、Mezusphere(メズスフェア)のグローバルエッジが認証フロー全体を処理します：

1. エンドユーザーが保護されたルートにリクエスト：エッジが有効なセッションを確認
2. セッションが見つからない：ユーザーがMezusphere(メズスフェア)のホスティングされたログインページにリダイレクト
3. ユーザーが認証：ログイン、サインアップ、パスワードリセット、メール確認をプラットフォームが処理
4. セッション確立：セッションが作成され、ユーザーがアプリケーションにリダイレクト
5. 後続リクエスト：エッジがセッションを検証し、認証済みトラフィックをWarpgate(ワープゲート)に転送

保護されたルートでは、ワークロードが未認証トラフィックを受け取ることはありません。リクエストがアプリケーションに到達する時点で、ユーザーのアイデンティティは検証済みです。

認証方式

Mezusphere(メズスフェア)自体がアイデンティティプロバイダーであり、連携する外部IdPは不要です。エンドユーザーは以下の方法で認証します：

• パスキー（WebAuthn）：フィッシング耐性のあるパスワードレスサインイン
• パスワード＋TOTP：パスワードアカウント向けの時間ベースワンタイムパスワード（TOTP）によるMFA
• メール確認とパスワードリセット：ホスティングされたログインフローに組み込み

プログラムによるアクセスや委任アクセスには、Mezusphere(メズスフェア)は必須PKCE（S256）付きのOAuth 2.1を実装し、OIDC id_tokenを発行します。OAuthクライアントはConsole(コンソール)で環境ごとに管理します。

ルートごとの設定

認証はルートレベルで設定され、きめ細かい制御が可能です：

同じプロジェクト内で公開ルートと認証済みルートを混在させることができます。アプリケーションレベルの認証ミドルウェアは不要で、エッジが適用を処理します。

認可ルール

認証に加えて、ルートには特定の権限を要求できます：

• ロールベースアクセス：特定のロールを持つユーザーにルートを制限
• パーミッションベースアクセス：ルートアクセスに特定のパーミッションを要求
• 複合ルール：認証と特定の認可クレームの両方を要求

認可ポリシーは認証と並行してエッジで適用されます。ワークロードは認証と認可の両方の要件を満たすトラフィックのみを受信します。

ユーザーディレクトリ

Mezusphere(メズスフェア)にはエンドユーザーアカウントを管理する組み込みのユーザーディレクトリが含まれています。ユーザーディレクトリはプロジェクトまたは組織にスコープされ、以下を提供します：

• アカウント作成：ホスティングされたログインフローでのサインアップ、またはConsole(コンソール)での作成
• アカウントライフサイクル：ユーザーアカウントの有効化、停止、無効化
• プロフィール管理：名前、メールアドレス、表示名、ステータス追跡
• ログイン履歴：認証イベントと最終ログインタイムスタンプの追跡

ユーザーディレクトリは、多くのプロダクト向けユースケースでAuth0、Cognito、Keycloakなどの個別のアイデンティティプロバイダーの必要性を置き換えます。アイデンティティ面はプラットフォームの一部であり、別のインテグレーションではありません。

サービスアカウントアイデンティティ

マシンは人間とは異なる方法で認証します。Mezusphere(メズスフェア)はマシン間アイデンティティにサービスアカウントを使用します：

• Warpgate(ワープゲート)認証：各Warpgate(ワープゲート)がサービスアカウントAPIキーを使ってコントロールプレーンに認証
• APIアクセス：サービスアカウントが設定可能な権限でMezusphere(メズスフェア)のAPIにアクセス
• プロジェクトスコープ：サービスアカウントは分離のため特定のプロジェクトにスコープ
• 即時取り消し：APIキーはConsole(コンソール)から即座にローテーションまたは取り消し可能

サービスアカウントは、人間のアイデンティティ（ユーザーディレクトリ）とマシンのアイデンティティ（サービスアカウント）をそれぞれ適切な認証メカニズムで明確に分離します。

アイデンティティ伝播

認証後、Mezusphere(メズスフェア)は信頼されたアイデンティティコンテキストを、転送リクエストのプレーンなHTTPヘッダーとしてワークロードに届けます：

これらのヘッダーは、認証の前にすべての受信リクエストから除去されるため、クライアントがなりすますことはできません。また、Mezusphere(メズスフェア)が発行したクレデンシャル（セッションクッキーとベアラートークン）はエッジで除去され、アプリケーションに届くことはありません。

アプリケーションは独自のトークン検証を実装せずにこのコンテキストを信頼できます：

1. エッジが転送前にアイデンティティを検証済み
2. Warpgate(ワープゲート)が第二の防御レイヤーとしてリクエストを検証
3. エッジとWarpgate(ワープゲート)間の接続がmTLSで保護

コードでアイデンティティを読む

// Node.js / Express
app.get("/api/orders", (req, res) => {
  const userId = req.get("Mz-User-Id");
  const email = req.get("Mz-User-Email");
  // ビジネスロジック。トークン解析も鍵セットも認証ミドルウェアも不要
});

// Go
func handler(w http.ResponseWriter, r *http.Request) {
	userID := r.Header.Get("Mz-User-Id")
	email := r.Header.Get("Mz-User-Email")
	// ビジネスロジック
}

コードにとっての意味

Mezusphere(メズスフェア)なしの場合、アプリケーションには通常以下が必要です：

• 認証SDKまたはライブラリ（Auth0 SDK、Passport.js、Spring Securityなど）
• トークン検証ミドルウェア
• セッション管理ロジック
• ユーザー管理エンドポイント
• パーミッションチェックコード

Mezusphere(メズスフェア)の場合、アプリケーションは信頼されたアイデンティティヘッダー付きの事前認証済みリクエストを受信します。ヘッダーを読んでビジネス上の判断を行うだけで、認証の配管工事は不要です。

事前認証済みトラフィック保証

認証が有効なルートでは、Warpgate(ワープゲート)に到達するすべてのリクエストが認証済みです。これは慣習やベストプラクティスではなく、アーキテクチャ上の保証です：

• 未認証リクエストはエッジでログインフローにリダイレクト
• 無効または期限切れのセッションを持つリクエストはエッジで拒否
• 認証・認可済みのリクエストのみがmTLSトンネルを通じてWarpgate(ワープゲート)に転送

ワークロードは「事前認証済みゾーン」で動作し、アイデンティティの問題はコードが実行される前にすでに解決されています。

プラットフォームが実装しているOAuthとOpenID Connectの仕様の正確な一覧は、標準仕様への準拠をご覧ください。