Spring NimbusJwtDecoder: праксі для загрузкі набору JWK

Дайце сервлетнаму дэкодару 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. Для публічнага URL JWK на дазволеным публічным проксі-маршруце спіс HTTP-проксі прапануе магчымыя значэнні хоста і порта.

Правяральнік issuer у прыкладзе не замяняе абавязковыя праверкі audience або іншыя праверкі праграмы. Захавайце іх пры замене аўтаматычна наладжанага дэкодара; змена маршруту загрузкі ключа не вызначае, якія токены павінна прымаць праграма.

Рэактыўны дэкодар выкарыстоўвае іншы інтэрфейс. Іншыя кліенты выяўлення issuer або атрымання токенаў таксама захоўваюць сваю ўласную канфігурацыю транспарту.

Кэшаваныя ключы могуць забяспечыць паспяховую праверку без новай загрузкі. Пры ацэнцы маршруту захоўвайце URL ключа, які не спрацаваў, і этап абнаўлення або ініцыялізацыі.

Падобныя артыкулы