シングルサインオン

シングルサインオン（SSO）を使うと、信頼できる外部の ID プロバイダーを通じて、ユーザーがセルフホスティングの Nodaro にログインできます。各プロバイダーを EXTERNAL_SSO_PROVIDERS 変数に記述すると、ログインページに SSO ボタンが表示されます。ユーザーが最終的に使うアカウントは、環境の通常のユーザーです。SSO は、セッションを開始する方法の 1 つにすぎません。このページでは、環境を運用する側の設定を説明します。プロトコルについては、開発者向けのシングルサインオンを参照してください。

使うプロバイダーの種類

SSO は、デフォルトでは無効です。EXTERNAL_SSO_PROVIDERS が未設定の場合、ログインページに SSO ボタンは表示されず、GET /v1/sso/providers は空のリストを返し、すべてのプロバイダーのルートが 404 unknown_provider を返します。

プロバイダーを設定する

EXTERNAL_SSO_PROVIDERS に、JSON 配列を設定します。値を直接書くか、@/path/to/providers.json の形式でファイルから読み込みます。

[
  {
    "id": "librechat",
    "label": "LibreChat",
    "kind": "assertion",
    "secret": "a-dedicated-32+char-hmac-key-not-the-idp-session-secret",
    "audience": "nodaro",
    "claimMap": { "email": "email", "emailVerified": "email_verified", "subject": "sub" },
    "initiateUrl": "https://chat.example.com/oauth/nodaro",
    "maxLifetimeSeconds": 300
  },
  {
    "id": "keycloak",
    "label": "Acme (Keycloak)",
    "kind": "oidc",
    "supabaseProvider": "keycloak"
  }
]

値の形式が正しくないと、起動が停止します。シークレットを含むエントリーに入力ミスがあっても、プロバイダーが黙って外されたり（SSO が 404 で失敗しているように見えます）、ログインが中途半端に設定されたりすることがあってはならないためです。

Compose スタックでは、EXTERNAL_SSO_PROVIDERS と EXTERNAL_SSO_LINK_EXISTING を、nodaro サービスの environment: に追加してください。Compose ファイルは、.env のこれらの変数をコンテナに渡さないためです。ファイルを使う場合は、ファイルをコンテナにマウントし、コンテナ内でのパスを指定します。

プロバイダーのフィールド

公開されるのは id、label、kind だけで、GET /v1/sso/providers を通じて公開されます。シークレットがサーバーの外に出ることはありません。

Nodaro がアサーションで確認すること

assertion プロバイダーの ID サーバーは JWT に署名し、ブラウザーを GET /v1/sso/<id>?assertion=<jwt> に送ります。Nodaro は、次の条件をすべて満たす場合にだけ、このアサーションを受け入れます。

• HS256 とプロバイダーの secret で署名されていること。
• aud が、プロバイダーの audience と一致すること。
• exp があり、期限が過ぎていないこと（許容誤差は 5 秒）。また、有効期間が maxLifetimeSeconds 以内であること。
• jti があり、一度も使われていないこと。各アサーションは 1 回しか使えません。
• メールアドレスのクレームがあること。アカウントを作成またはリンクするには、確認済みを示すクレームが true である必要があります。

確認に失敗すると、401 が返ります。このルートは、1 つの IP アドレスから 60 秒あたり 20 回までのリクエストを受け付け、それを超えると 429 を返します。仕様の全体、エラーコード、リダイレクトの流れは、開発者向けのシングルサインオンにあります。

アカウントのリンク方法

アサーションが確認を通過すると、Nodaro は該当するユーザーを探すか、新しく作成します。次のルールにより、メールアドレスが同じというだけで、アサーションが既存のアカウントを乗っ取ることはできません。

EXTERNAL_SSO_LINK_EXISTING のデフォルトは false で、乗っ取りに対して安全です。有効になるのは true か 1 の場合だけです（大文字と小文字は区別しません）。有効にするのは、プロバイダーの「メールアドレス確認済み」のクレームを、既存のアカウントに結び付けてよいと言えるほど信頼できる場合だけにしてください。

account_exists と email_unverified は、どのアカウントでも同じ文言を使います。そのため、ログインフォームを使って、どのアドレスが存在するかを探ることはできません。どのアカウントが対象になったかは、サーバーのログに記録されます。

ログインボタン

プロバイダーが 1 つ以上設定されていると、ログインページに SSO ボタンが表示されます。

• プロバイダーが 1 つの場合：ボタンにはシングルサインオン、またはサーフェスプロファイルの auth.ssoLabel が表示されます。
• プロバイダーが複数の場合：サーフェスプロファイルで auth.ssoLabel が設定されていなければ、各ボタンにはそのプロバイダーの label が表示されます。

ログイン後、ユーザーは /projects に移動します。プロバイダーは、リダイレクトで戻すときに &next=<path> を付けて、別のページを指定できます。Nodaro がこの指定に従うのは、同じオリジン上の相対パスで、/ で始まり、// で始まらない場合だけです。それ以外の場合は /projects に移動します。CORS_ORIGIN に列挙されたホストでは、ログイン後のリダイレクトは相対パスのままで、ユーザーがアクセスしてきたホストにとどまります。

SSO によるログインだけを許可する

Business エディションでは、サーフェスプロファイルで、ほかのログイン方法を無効にできます。

NODARO_SURFACE_PROFILE={"auth":{"methods":["sso"],"ssoLabel":"Sign in with Acme"}}

リストに sso だけを指定すると、サーバー側のルールも有効になります。ログインするすべてのアカウントは、SSO を通じて作成またはリンクされている必要があります。それ以外のセッションは、最初の API 呼び出しで 403 sso_required によって拒否されます。そのため、ログインサービスに直接登録したアカウントは、この環境を使えません。リストに email を加えると、このルールは無効になります。エディションとサーフェスプロファイルを参照してください。

セキュリティのまとめ

• 専用のシークレット：プロバイダーごとに、プロバイダー自身のセッションシークレットとは別のシークレットを使います。
• 1 回限りのアサーション：有効期間は短く、サーバー側で強制されます。
• 同一オリジンへのリダイレクトのみ：ログイン後のリダイレクト先は、同じオリジンに限られます。
• シークレットはサーバーの外に出ません。アサーションとワンタイムトークンは、リクエストログから削除されます。
• レート制限：交換用のルートには、IP アドレスごとのレート制限があります。
• 通常のセッション：交換のあと、ユーザーは特別な認証情報を持たない通常のユーザーになります。