受信した 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 と更新または初期化の段階を保持してください。

関連記事