匿名マルチテナントAPIエンドポイントのテナントの決定
マルチテナンシーをサポートする必要のある新しいAPIを作成中です。
クライアントが他のテナントデータを知る（または参照する）ことを心配する必要なく、データの読み取りと書き込みを安全に実装する方法を理解できます。
また、認証されたエンドポイントに適切なテナントを決定する方法も理解できます（つまり、JWTでテナントIDを使用します）。
ただし、匿名のエンドポイントの場合、これにどのように取り組むかわかりません。私は次の解決策を思いつきました：
解決策1：
テナントIDをパラメーターとして追加します。マルチテナンシーがリソースエンドポイントの一部にならないようにしたいので、これは嫌いです。
長所：
- 実装が簡単
短所
- マルチテナンシーが「透明」であるとは思わない
解決策2：
匿名トークンを生成できるテナントサービスを作成します（サブを設定せず、テナントIDのみ）。
長所
- マルチテナンシーに透明性を追加します
- 後の段階で、このトークンをユーザークレデンシャルとともに交換トークンとして使用して、マルチテナント認証サービスに対して認証できます。
短所
- 別の「認証エンドポイント」を追加します
解決策3：
アプリケーショントークンを使用します。その後、各テナントは、それぞれがキーとシークレットで認証する複数のクライアントを持つことができます。これは2番目のソリューションを拡張し、それに独自の利点と欠点があります：Pros
- クライアントは自分自身でユーザーになる
- スコープを持つ可能性
短所：
- 複雑さが増します（マルチテナントクライアントには複数のトークンが必要です）
- 管理を追加します。各クライアントには、テナントごとにアプリケーショントークンが必要です
質問
これはこれらのエンドポイントを作成する上で重要な部分であるため（そして、エンドポイントの多くになる可能性があります）、これらのソリューションについてのあなたの意見を聞きたいと思います。このパターンが見つかりません。これに関するあなたのインプットは大いに感謝されます。
Hostヘッダーの一部としてテナントを渡すことを検討してください。すなわち
{tennant}.myapi.com/{resource}/{action}
これにより、透明性に関する懸念が解消され、各テナントが分離されます。
考えられる欠点は、マルチテナントクライアントに複数のエンドポイントを追加することです。しかし、これは分離を維持するため、いくつかの点で良いことだと考えられます。