אַ אַרייַנקומענדיקע 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-פּראָקסי רשימה מעגלעכע host- און port-ווערטן.

דער issuer-וואַלידאַטאָר אין בײַשפּיל איז נישט קיין פֿאַרבייַט פֿאַר פֿאָדערלעכע audience- אָדער אַנדערע אַפּליקאַציע-פּרובֿן. האַלט זיי בשעת איר פֿאַרבייט אַן אויטאָמאַטיש קאָנפֿיגורירטן דעקאָדער; פֿאַרבייטן דעם שליסל-אַראָפּלאָדונג וועג באַשטימט נישט וועלכע token די אַפּליקאַציע זאָל אָננעמען.

אַ רעאַקטיווער דעקאָדער ניצט אַן אַנדער צובינד. אַנדערע קליענטן פֿאַר issuer-אַנטדעקונג אָדער token-באַקומען האַלטן אויך זייער אייגענע טראַנספּאָרט-קאָנפֿיגוראַציע.

קאַשירטע שליסלען קענען מאַכן די וועריפֿיקאַציע מצליח אָן אַ נײַעם אַראָפּלאָדונג. האַלט דעם URL פֿון דעם דורכגעפֿאַלענעם שליסל און דעם דערפֿרישונג- אָדער איניציאַליזירונג-שריט בשעת איר אָפּשאַצט דעם וועג.

פֿאַרבונדענע אַרטיקלען