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 адреса на неуспешния ключ и етапа на опресняване или инициализация, когато оценявате маршрута.

Подобни статии