未知のソースからopenid-connectリクエストを制限する方法。未知のソースからopenid-connect userinfoリクエストを制限する
利用可能なアクセストークンがあれば誰でも私たちが制限したいと思うuserinfo（ユーザー情報とクレームをuserinfoに保存しています）をリクエストできます。
は、既知のクライアントからのみ許可する必要があるということを意味します。
注：私たちは、アイデンティティ・サーバーとしてKeycloakを使用している
助けてください！
まず、アクセストークンはユーザーの資格情報と同じように保護する必要があります。 OAuth2.0フレームワークが私たちに与えることは、ユーザ名/パスワードに基づく認証/認可を動的に生成されたトークンに置き換えることができることです。したがって、これらのトークンは保護する必要があります。そのため、TLSはトークンの送信に必須です。
RFC6749 section 10.3 - アクセストークン資格証明書（ならびに任意の 機密アクセストークンの属性）は、アクセストークンが有効ですリソースサーバ、 輸送や保管に機密保持、そして唯一の認可 サーバー間で共有されなければなりませんアクセストークンが発行されたクライアント が含まれています。アクセストークン は、 セクション1.6 [RFC2818]で定義されているサーバー認証で説明されているように、TLSを使用してのみ送信する必要があります。
アクセストークンの悪用を心配している場合は、まずトークンベースの通信を採用することを心配する必要があります。クライアントは、トークンを誤用しないように十分に保護されていなければなりません。
また、CORSヘッダーを有効にして、エンドポイントへのアクセスを制限することもできます。しかし、これはトークンを保護した後です。
p.sまた、既知の有効なIPアドレスだけがバックエンドと通信できるようにネットワーク設定を変更することもできます。しかし、それはOIDCプロトコルの外です。
ありがとうございます！しかし、私は実際の答えを得ていないし、はい、私たちはアクセストークンを保護しています。実際には、未知のソースまたは郵便配達のいずれかを介してアクセストークンを持っていれば、どのユーザもuserinfoの権利を要求することができます。私はこれを制限したい。リクエストが当社のクライアント（マイクロサービス）のみから来た場合は詳細を共有します。 – Nick
@ニックこの例のように、有効なアクセストークンを使って郵便配達要求を送信しないでください。つまり、アクセストークンが保護されており、他の当事者がそれを取得できない場合、userinfoエンドポイントから情報を取得することはできません。プロトコルの保護はアクセストークンに制限されています（私の答えはその理由を説明しています）。あるいは、意図したオーディエンス以外のIPアドレスをブラックリストに登録するためにネットワークを調整することもできます。しかし、それはネットワークの観点からです。 –