Eine eingehende Bearer-Anfrage kann den Ressourcenserver erreichen, während die JWT-Prüfung bei einem ausgehenden JWK-Download fehlschlägt. Konfigurieren Sie den HTTP-Client, den dieser Decoder verwendet:

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

Verwenden Sie die echten jwkSetUri und issuer der Anwendung und installieren Sie diesen Decoder in der tatsächlichen Ressourcenserver-Konfiguration. Das Beispiel verwendet einen nicht authentifizierten HTTP-Proxy mit dem Nimbus-Decoder im Servlet-Stil. Für eine öffentliche JWK-URL auf einer zulässigen öffentlichen Proxy-Route liefert die HTTP-Proxy-Liste mögliche Host- und Portwerte.

Der Issuer-Validator im Beispiel ersetzt keine erforderlichen Audience- oder anderen Anwendungsprüfungen. Behalten Sie diese beim Ersetzen eines automatisch konfigurierten Decoders bei; das Ändern der Schlüssel-Download-Route legt nicht fest, welche Tokens die Anwendung akzeptieren soll.

Ein reaktiver Decoder verwendet eine andere Schnittstelle. Andere Clients zur Issuer-Erkennung oder Token-Beschaffung behalten ebenfalls ihre eigene Transportkonfiguration.

Zwischengespeicherte Schlüssel können die Prüfung ohne einen neuen Download gelingen lassen. Merken Sie sich beim Bewerten der Route die fehlgeschlagene Schlüssel-URL und die Aktualisierungs- oder Initialisierungsphase.

Ähnliche Artikel