Spring NimbusJwtDecoder: проксирање на преземањето на множеството JWK

Дајте му на servlet декодерот RestTemplate што го познава проксито и задржете ги валидаторите на issuer, audience и дополнителните валидатори на токени при замена на автоматската конфигурација.

Влезното bearer барање може да стигне до серверот за ресурси додека проверката на JWT не успее при излезно преземање на JWK. Конфигурирајте го HTTP клиентот што го користи тој декодер:

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

Користете ги вистинските jwkSetUri и issuer на апликацијата и инсталирајте го овој декодер во вистинската конфигурација на серверот за ресурси. Примерот користи неавтентифицирано HTTP прокси со Nimbus декодер во servlet стил. За јавен JWK URL на дозволена јавна прокси рута, списокот со HTTP прокси нуди можни вредности за хост и порта.

Валидаторот на issuer во примерот не ги заменува задолжителните проверки на audience или другите проверки на апликацијата. Задржете ги при замена на автоматски конфигуриран декодер; промената на рутата за преземање на клучот не одредува кои токени апликацијата треба да ги прифати.

Реактивниот декодер користи друго интерфејс. Другите клиенти за откривање issuer или добивање токени исто така ја задржуваат сопствената транспортна конфигурација.

Кешираните клучеви можат да овозможат успешна проверка без ново преземање. Задржете го URL-то на неуспешниот клуч и фазата на освежување или иницијализација при проценка на рутата.

Поврзани статии