O cerere bearer de intrare poate ajunge la serverul de resurse în timp ce verificarea JWT eșuează la o descărcare JWK de ieșire. Configurați clientul HTTP pe care îl folosește acel decodor:

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

Folosiți jwkSetUri și issuer reale ale aplicației și instalați acest decodor în configurația reală a serverului de resurse. Exemplul folosește un proxy HTTP neautentificat cu decodorul Nimbus în stil servlet. Pentru un URL JWK public pe o rută de proxy public permisă, lista de proxy-uri HTTP oferă valori candidate de gazdă și port.

Validatorul issuer din exemplu nu înlocuiește verificările de audience obligatorii sau alte verificări ale aplicației. Păstrați-le la înlocuirea unui decodor configurat automat; schimbarea rutei de descărcare a cheii nu definește ce tokenuri ar trebui să accepte aplicația.

Un decodor reactiv folosește altă interfață. Alți clienți de descoperire a issuer sau de obținere a tokenurilor își păstrează, de asemenea, configurația proprie de transport.

Cheile din cache pot face verificarea reușită fără o descărcare nouă. Păstrați URL-ul cheii eșuate și etapa de reîmprospătare sau inițializare când evaluați ruta.

Articole similare