Spring NimbusJwtDecoder: proxy per il download del set JWK

Date al decoder servlet un RestTemplate consapevole del proxy e conservate i validatori issuer, audience e token aggiuntivi quando sostituite la configurazione automatica.

Una richiesta bearer in ingresso può raggiungere il server delle risorse mentre la verifica JWT fallisce su un download JWK in uscita. Configurate il client HTTP usato da quel decoder:

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));

Usate i veri jwkSetUri e issuer dell'applicazione e installate questo decoder nella configurazione reale del server delle risorse. L'esempio usa un proxy HTTP non autenticato con il decoder Nimbus in stile servlet. Per un URL JWK pubblico su una rotta proxy pubblica consentita, la lista di proxy HTTP fornisce valori candidati di host e porta.

Il validatore issuer dell'esempio non sostituisce i controlli audience obbligatori né altri controlli dell'applicazione. Conservateli quando sostituite un decoder configurato automaticamente; cambiare la rotta di download delle chiavi non definisce quali token l'applicazione debba accettare.

Un decoder reattivo usa un'altra interfaccia. Anche gli altri client di scoperta dell'issuer o di acquisizione dei token mantengono la propria configurazione di trasporto.

Le chiavi in cache possono far riuscire la verifica senza un nuovo download. Conservate l'URL della chiave non riuscita e la fase di aggiornamento o inizializzazione quando valutate la rotta.

Articoli correlati