SSOおよびテナントごとに異なるロールを使用したマルチテナントAPIの保護
REST開発するファーストパーティクライアントと将来的にサードパーティクライアントで使用されるAPIの開発に取り組んでいます。ファーストパーティクライアントには、SPAクライアント側のアプリケーションとプログラムが含まれていますクライアントPCで実行されます（シークレットのセキュリティは保証できません）。
さらに、このAPIは疑似マルチテナントです。複数のテナントがあり、各テナントは1つ以上のアクティブなインスタンスをAPIに持つことができ、それぞれに独自のセキュリティロールのセットがあり、それぞれにさまざまな権限があります。ただし、このデータはすべて同じデータベースに保存されるため、ユーザーは作業中のインスタンス（テナント内とテナント外の両方）を切り替えることができます。ログインは、サードパーティプロバイダー（Facebook/Googleなど）を使用して許可できます。また、サインインにより、再認証なしで他のインスタンスにアクセスできるようになります。
APIのマルチテナント/マルチロールの性質を考慮して、認証/承認ロジックをどのように実装するべきかについて、少し混乱しています。 OpenID Connect認証をAPIに実装し、OAuthを使用して、ユーザーが試行している特定のインスタンスへのアクセスを委任するのが正しい方法だと私が考えていることです。私の混乱は、どのトークンをどこで使用するかを決定しようとしていますが、ユーザーがSPAにサインインしたままで、インスタンスを変更できるようにしたいと考えています。
マルチテナント/マルチデータベースのセキュリティ保護に関する情報を見ましたREST apiのですが、役割は一貫しているように見えるため、さまざまな役割を持つ1つのデータベースへの処理を推定することはできません。
だからこれらは私の質問です：
- この情報を踏まえて、OpenID ConnectとOAuth2を使用することは正しいですか？
- OpenID Connectでは、委任するスコープをアドバタイズできるようです。これは、認証後、テナントが判明するまで、不確定な役割でどのように処理されますか？
- OAuth（私がしたいこと））を介して個々の権限を委任することは正しいですか、またはOAuthインスタンスとアプリケーションごとに割り当てられたロールを委任するだけです）次に、権限を検索する必要がありますか？
- 2つの個別のトークンが必要です。1つは一般的な認証用で、もう1つはインスタンスごとの承認用です。これらをAPIに渡すための標準は何でしょうか。現在、JWTとAuthorization Bearerヘッダーを使用しています。私は1つのトークンの単純さを気に入っていますが、調整する必要がある場合は、修正できます。
私はこれについて1〜2週間記事を探していましたが、自分の状況に最適なフローのタイプと、インスタンス間の変動をどのように処理するかを明確にするのに役立つものは見つかりませんでした。見逃した記事がある場合は、コメントとして追加してください。レビューも行います。
私はプログラマではありませんが、同様のことをしていると思われる組織をレビューしました。ここに彼らがそれをする方法があります...
AngularJSクライアントは、OAuthを介して持っているアプリケーションセキュリティAPIで認証します。次に、APIをホストするシステムが認証を渡し、2番目のシステムに許可を要求します。 2番目のシステムは、authZトークン、ユーザー名、およびクレームをセキュリティAPIシステムに返します。セキュリティAPIは、JWTを作成してセキュリティAPIシステムに返すトークンマネージャーシステムを呼び出します。最後に、セキュリティAPIはエンコードされたJWTをAngularJSクライアントに返します。
個別の呼び出しは、AngularJSクライアントから実際のアプリケーションAPIに渡され、トークンを提供します。アプリケーションAPIシステムは、検証のためにトークンをトークンマネージャーに渡します。有効な場合、APIはデータを返します（または無効なトークンや期限切れのトークンをスローします）。
更新の場合、AngularJSクライアントは再度セキュリティAPIにアクセスし、authZトークンシステムにアクセスして、更新されたトークンをセキュリティAPIシステムに返します。これにより、トークンがトークンマネージャーに送信され、新しいJWTが作成されて、セキュリティAPIがクライアント。
テナントの変更時に、セキュリティAPIへのauthZトークン転送要求の呼び出しを行い、authZトークンサーバーに到達すると、新しいauthZトークンが作成され、ユーザー名とロールと共にセキュリティAPIに送り返されます。 JWTとそれが返されたら、それをクライアントに渡します。
質問に直接回答するには...
- OAuthおよびOIDCを使用することは正しいようです
- スコープアドバタイズについては知りません。
- 私はセキュリティを確保しているので、すべてに対してロールベースのアクセス制御のファンです。 :-Dしたがって、アプリケーションに、トークンに埋め込まれたロールから個々のパーマルックアップを実行させるといいます。
- 2つの別個のトークンが、この組織がそれを処理する方法であるように見えます。 1つは、IDとセッションIDの両方として機能するようです。 2つ目は、最初のトークンと現在のテナントのロール/クレームを含むJWTです。