Spring NimbusJwtDecoder: JWK セットのダウンロードをプロキシ経由にする
servlet デコーダーにプロキシ対応の RestTemplate を渡し、自動構成を置き換える際に issuer、audience、および追加のトークン検証器を保持します。
受信した bearer リクエストがリソースサーバーに届いても、外向きの JWK ダウンロードで JWT 検証が失敗することがあります。そのデコーダーが使う HTTP クライアントを構成します:
var factory = new org.springframework.http.client.SimpleClientHttpRequestFactory();
factory.setProxy(new java.net.Proxy(
java.net.Proxy.Type.HTTP,
new java.net.InetSocketAddress("proxy.example", 8080)));
var rest = new org.springframework.web.client.RestTemplate(factory);
var decoder = org.springframework.security.oauth2.jwt.NimbusJwtDecoder
.withJwkSetUri(jwkSetUri)
.restOperations(rest)
.build();
decoder.setJwtValidator(
org.springframework.security.oauth2.jwt.JwtValidators
.createDefaultWithIssuer(issuer));アプリケーションの実際の jwkSetUri と issuer を使い、このデコーダーを実際のリソースサーバー構成に組み込みます。例では servlet 形式の Nimbus デコーダーと認証なしの HTTP プロキシを使います。許可された公開プロキシ経路の公開 JWK URL については、HTTP プロキシ一覧が候補のホストとポートの値を提供します。
例の issuer 検証器は、必須の audience やその他のアプリケーション検査の代わりにはなりません。自動構成されたデコーダーを置き換える際はそれらを保持してください。鍵のダウンロード経路を変えても、アプリがどのトークンを受け入れるかは定義されません。
リアクティブなデコーダーは別のインターフェースを使います。issuer 検出やトークン取得の他のクライアントも、それぞれ独自のトランスポート構成を保ちます。
キャッシュされた鍵があれば、新しいダウンロードなしで検証が成功することがあります。経路を評価する際は、失敗した鍵の URL と更新または初期化の段階を保持してください。