Մուտքային 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 պրոքսի servlet ոճի Nimbus ապակոդավորիչով։ Թույլատրված հանրային պրոքսի երթուղու հանրային JWK URL-ի համար HTTP պրոքսիների ցանկը տալիս է հոսթի և պորտի հավանական արժեքներ։

Օրինակի issuer վավերացուցիչը չի փոխարինում պարտադիր audience կամ հավելվածի այլ ստուգումներին։ Պահպանեք դրանք ավտոմատ կարգավորված ապակոդավորիչը փոխարինելիս. բանալու ներբեռնման երթուղու փոփոխությունը չի սահմանում, թե որ token-ները հավելվածը պետք է ընդունի։

Ռեակտիվ ապակոդավորիչն օգտագործում է այլ ինտերֆեյս։ Issuer-ի հայտնաբերման կամ token-ի ձեռքբերման այլ հաճախորդներ նույնպես պահպանում են իրենց փոխադրման կոնֆիգուրացիան։

Քեշավորված բանալիները կարող են ստուգումը հաջողեցնել առանց նոր ներբեռնման։ Երթուղու գնահատման ժամանակ պահեք ձախողված բանալու URL-ը և թարմացման կամ սկզբնավորման փուլը։

Առնչվող հոդվածներ