Spring NimbusJwtDecoder: proxy foar it downloaden fan de JWK-set

Jou de servlet-dekoder in proxybewuste RestTemplate en behâld de issuer-, audience- en ekstra tokenfalidearers by it ferfangen fan 'e automatyske konfiguraasje.

In ynkommend bearer-fersyk kin de boarneserver berikke wylst JWT-ferifikaasje mislearret by in útgeand JWK-download. Konfigurearje de HTTP-klient dy't dy dekoder brûkt:

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

Brûk de echte jwkSetUri en issuer fan 'e applikaasje en ynstallearje dizze dekoder yn 'e werklike boarneserver-konfiguraasje. It foarbyld brûkt in net-autentisearre HTTP-proxy mei de Nimbus-dekoder yn servlet-styl. Foar in iepenbiere JWK-URL op in tastiene iepenbiere proxy-route jout de HTTP-proxylist kandidaatwearden foar host en poarte.

De issuer-falidearers yn it foarbyld ferfange de ferplichte audience-kontrôles of oare applikaasjekontrôles net. Behâld dy by it ferfangen fan in automatysk konfigurearre dekoder; it feroarjen fan 'e kaai-downloadrûte bepaalt net hokker tokens de applikaasje akseptearje moat.

In reaktive dekoder brûkt in oare ynterface. Oare kliïnten foar issuer-ûntdekking of token-oanwinst behâlde ek har eigen transportkonfiguraasje.

Cachede kaaien kinne de ferifikaasje slagje litte sûnder in nije download. Behâld de URL fan 'e mislearre kaai en de fernijings- of initialisaasjefaze by it beoardieljen fan 'e rûte.

Relatearre artikelen