OIDCを使用したマイクロサービスとRBAC
現在、ユーザーの内部DBからOIDCサービスへの移行（Cognito/Auth0/etcを考慮）に取り組んでおり、RBACを実装しようとしています。
私たちのバックエンドは基本的には一連のマイクロサービスであり、各サービスが独自のソリューションを実装せずに、それらすべてが呼び出さなければならない中央サービスを持たずに、サービスのACLを管理する方法を理解しようとしています（単一障害点）。
ソリューションがどのように見えるかを想像しているのは、署名され、すべてのユーザー権限を主張として保持するJWTアクセストークンを持っていることですが、それを行う実装を見つけることができないため、何かが欠けているようです。
これらのクレームをIDトークンに追加できることは確認しましたが、理解できるように、 IDトークンをアクセストークンとして渡すべきではありません 。何か不足していますか？マイクロサービス環境では通常どのように行われますか？
編集： Auth0は私たちのユースケースをサポートしています であり、Cognitoはそうではありません...それでも、それが私たちが計画している方法で実装することをお勧めします
IDトークンとアクセストークンは、OIDCで2つの異なる目的を果たします。
IDトークン=ユーザーのIDを確認するため。ユーザーは誰ですか？彼らのメールアドレスは何ですか？
アクセストークン=ユーザーがアクセスを許可されているかどうかを確認します。アクセストークンの署名が有効な場合は、アクセスを許可します。通常、アクセスを確認するために必要な情報が含まれます（たとえば、一部のID情報、ロール、場合によっては権限など）。
アクセス関連のクレームについては、「IDクレーム（アドレスなど）」でない限り、アクセストークンにのみ追加する必要があります。
個別の承認サービスに関する限り、アプリケーションが多数のアクセス許可とロールを処理しない場合は、それらをクレームとしてアクセストークンに追加するだけでよいと思います。
非常に多数の役割と権限がある場合、これはトークンの肥大化につながります（Davidのコメントで述べたとおり）。この場合、個別の承認サービスが理にかなっています。この許可サービスは、権限マッピングに役割を果たし、権限を評価するためのAPIを提供する必要があります。ユーザーの役割をアクセストークンに保持します。権限が評価されたら、役割のアクセストークンを確認し、権限の有効性を判断します。権限を評価するときは、アクセストークンを渡すことを忘れないでください。この方法はどのくらい一般的ですか？ ONAPは 同様のアプローチ を使用しているようです。
私は専門家ではありませんが、ここに行きます。
JWTアクセストークンは、ユーザーの認証後に発行されます。つまり、ユーザーのユーザー名/パスワード（およびいくつかの2FAピースも）をすでに検証済みです。
JWTの秘密は、署名されていることです（対称暗号化または非対称暗号化のいずれかで）。つまり、共有秘密鍵または公開鍵（使用されている暗号化タイプに応じて異なる）を持っている場合は、だれでもJWTを検証できます。
これにより、JWTの発行をJWTの検証から分離できるため、単一のサービスでユーザーのセッションIDまたは同様のトークンを確認する必要がなくなります。
非対称暗号化の場合、APIエンドポイントで実際に必要なのは公開鍵と、トークンのスコープでトークンへのアクセスが許可されているかどうかを判断するロジックだけです。 APIの認証と承認の両方を処理します。
しかし、これには欠点があり、JWTトークンが失われた場合はどうなりますか？ユーザーセッションをリセットして、ユーザーに再度ログオンさせるにはどうすればよいですか？
これを行うには、accessトークンとrefreshトークンの概念を使用します。アクセストークンは、各APIリクエストで提供されるもので、通常15分の有効期間があります。これは、各エンドポイントによって検証されるトークンに有効期限を設定する発行サービスによって処理されます。
refreshトークンは、APIに渡されることを意図していませんが、アクセストークンの有効期限が切れた（またはほぼ期限切れになる）ときに1回だけ使用されます。更新トークンが認証に渡され、両方のトークンの新しいペアが取得されます。
これにより、発行サービスの更新トークンを強制終了し、緊急時にすべてのユーザーに再認証を強制できます。もちろん、変更はすぐには行われませんが、トークンの有効期間が有効になります。セッションIDを保持する共有DBがある場合、これは通常すぐに行われますが、これは単一障害点がないことの欠点です。
ID Tokenが入ってきます-しかし、私が疑っているのは、これはOpenIDと関係があるためであり、必ずしもJWT認証ではないということです。お役に立てば幸いです。