Spring NimbusJwtDecoder: verteenwoordig die aflaai van die JWK-stel

Gee die servlet-dekodeerder 'n proxy-bewuste RestTemplate en behou die uitgewervalideerder, gehoor en bykomende tokenvalideerders wanneer outo-konfigurasie vervang word.

'n Inkomende bearer-versoek kan die hulpbronbediener bereik terwyl JWT-verifikasie misluk op 'n uitgaande JWK-aflaai. Konfigureer die HTTP-kliënt wat deur daardie dekodeerder gebruik word:

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

Gebruik die toepassing se werklike jwkSetUri en issuer, en installeer hierdie dekodeerder in die werklike hulpbronbediener-konfigurasie. Die voorbeeld gebruik 'n ongeverifieerde HTTP-proxy met die servlet-styl Nimbus-dekodeerder. Vir 'n openbare JWK-URL op 'n toegelate openbare-proxy-roete verskaf die HTTP-proxylys kandidaat-gasheer- en -poortwaardes.

Die uitgewervalideerder in die voorbeeld is nie 'n plaasvervanger vir vereiste gehoor- of ander toepassingstoetse nie. Behoud dit wanneer 'n outomaties gekonfigureerde dekodeerder vervang word; die verandering van die sleutel-aflaairoete bepaal nie watter tokens die toepassing moet aanvaar nie.

'n Reaktiewe dekodeerder gebruik 'n ander koppelvlak. Ander uitgewervindings- of tokenverkrygingskliënte behou ook hul eie vervoerkonfigurasie.

Gekasde sleutels kan verifikasie laat slaag sonder 'n nuwe aflaai. Hou die mislukte sleutel-URL en die verversings- of inisialiseringsfase by wanneer die roete beoordeel word.

Verwante artikels