Een inkomend bearer-verzoek kan de resourceserver bereiken terwijl JWT-verificatie mislukt bij een uitgaande JWK-download. Configureer de HTTP-client die die decoder gebruikt:

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

Gebruik de echte jwkSetUri en issuer van de applicatie en installeer deze decoder in de werkelijke resourceserver-configuratie. Het voorbeeld gebruikt een niet-geauthenticeerde HTTP-proxy met de Nimbus-decoder in servlet-stijl. Voor een openbare JWK-URL op een toegestane openbare proxy-route biedt de HTTP-proxylijst kandidaatwaarden voor host en poort.

De issuer-validator in het voorbeeld vervangt niet de vereiste audience-controles of andere applicatiecontroles. Behoud die bij het vervangen van een automatisch geconfigureerde decoder; het wijzigen van de sleutel-downloadroute bepaalt niet welke tokens de applicatie moet accepteren.

Een reactieve decoder gebruikt een andere interface. Andere clients voor issuer-detectie of tokenverwerving behouden ook hun eigen transportconfiguratie.

Gecachte sleutels kunnen de verificatie laten slagen zonder een nieuwe download. Bewaar de URL van de mislukte sleutel en de vernieuwings- of initialisatiefase bij het beoordelen van de route.

Gerelateerde artikelen