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 عمومی در مسیر مجاز پروکسی عمومی، فهرست پروکسی HTTP مقادیر میزبان و پورت نامزد را فراهم می‌کند.

اعتبارسنج issuer در مثال جایگزین بررسی‌های الزامی audience یا سایر بررسی‌های برنامه نیست. هنگام جایگزینی رمزگشای پیکربندی‌شده به‌صورت خودکار آن‌ها را حفظ کنید؛ تغییر مسیر دانلود کلید تعیین نمی‌کند که برنامه چه توکن‌هایی را باید بپذیرد.

رمزگشای واکنشی از رابط دیگری استفاده می‌کند. سایر کلاینت‌های کشف issuer یا دریافت توکن نیز پیکربندی انتقال خودشان را حفظ می‌کنند.

کلیدهای ذخیره‌شده در حافظهٔ نهان می‌توانند تأیید را بدون دانلود جدید موفق کنند. هنگام ارزیابی مسیر، نشانی کلید ناموفق و مرحلهٔ تازه‌سازی یا راه‌اندازی را نگه دارید.

مقالات مرتبط