Une requête bearer entrante peut atteindre le serveur de ressources alors que la vérification JWT échoue lors d'un téléchargement JWK sortant. Configurez le client HTTP utilisé par ce décodeur :

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

Utilisez les vrais jwkSetUri et issuer de l'application et installez ce décodeur dans la configuration réelle du serveur de ressources. L'exemple utilise un proxy HTTP non authentifié avec le décodeur Nimbus de style servlet. Pour une URL JWK publique sur une route de proxy public autorisée, la liste de proxys HTTP fournit des valeurs d'hôte et de port candidates.

Le validateur issuer de l'exemple ne remplace pas les contrôles d'audience obligatoires ni les autres contrôles de l'application. Conservez-les lors du remplacement d'un décodeur configuré automatiquement ; modifier la route de téléchargement des clés ne définit pas quels jetons l'application doit accepter.

Un décodeur réactif utilise une autre interface. Les autres clients de découverte d'issuer ou d'obtention de jetons conservent également leur propre configuration de transport.

Les clés mises en cache peuvent faire réussir la vérification sans nouveau téléchargement. Conservez l'URL de la clé en échec et l'étape d'actualisation ou d'initialisation lors de l'évaluation de la route.

Articles similaires