Logto v1.43.0 เพิ่มแอปไดนามิกด้วย OAuth Client ID Metadata Documents, คำขอรับรองความถูกต้อง SAML ที่ลงนาม, ขอบเขตการทำงานของ Custom JWT และ Actions, การตรวจสอบความถูกต้องในการแลกเปลี่ยนโทเค็นที่แข็งแกร่งขึ้น, และการป้องกัน SSRF ที่ขยายสำหรับ webhook และ SSO องค์กร
Logto v1.43.0 ขยายวิธีที่แอปพลิเคชันและผู้ให้บริการข้อมูลประจำตัวองค์กรเชื่อมต่อกัน พร้อมเสริมสร้างขอบเขตความปลอดภัยสำหรับโทเค็นและคำขอออกภายนอก โดยเปิดตัวแอปไดนามิกด้วย OAuth Client ID Metadata Documents, คำขอรับรองความถูกต้อง SAML ที่ลงนาม, และ runtime รวมสำหรับ Custom JWT และ Actions รุ่นนี้ยังเสริมความปลอดภัยการแลกเปลี่ยนโทเค็น, webhook, และ SSO องค์กร พร้อมปรับปรุง Account Center, รองรับภาษาสเปน (เม็กซิโก) และแก้ไขความเสถียร นี่คือสิ่งใหม่ ๆ ที่มีมา
ประสบการณ์การลงชื่อเข้าใช้รองรับ es-MX (สเปน, เม็กซิโก) แล้ว
สำหรับผู้ใช้ที่ตั้งค่าภาษาเป็นสเปน (เม็กซิโก) ช่องกรอกเบอร์โทรศัพท์จะตั้งรหัสประเทศเม็กซิโก (+52) เป็นค่าเริ่มต้น รุ่นนี้ยังแก้ไขตัวแปร placeholders สำหรับตัวจัดรูปแบบรายการและข้อความ MFA ที่ยังไม่แปลในภาษาสเปน
คำขอออกภายนอกที่กำหนดค่าผ่าน Management API จะถูกบล็อกเมื่อไม่สามารถส่งไปยัง loopback, private, link-local, cloud metadata หรือที่อยู่พิเศษอื่น ๆ
การป้องกันจะครอบคลุมถึง:
POST /api/hooks/:id/testDNS names จะถูกตรวจสอบเมื่อมีการเชื่อมต่อ ดังนั้น hostnames ที่ resolve ไปเป็นที่อยู่ที่ป้องกันจะถูกปฏิเสธเหมือนกับ IP address โดยตรง
นอกจากต้องใช้โทเค็นผู้ใช้จากแอป first-party ตอนนี้ Logto จะตรวจสอบด้วยว่า JWT ที่ถูกส่งมาเป็น subject ของ access_token จริง ๆ ต้องเป็น access token
JWT ต้องมี:
at+jwt ตาม RFC 9068client_idOIDC ID tokens และ JWT อื่น ๆ ที่ลงนามโดย tenant จะไม่สามารถแทนที่ access token ได้อีก subject token ที่ไม่ถูกต้องจะถูกปฏิเสธด้วย invalid_grant
แอป third-party ไม่สามารถแก้ไขข้อมูลบัญชีผ่าน Account API หรือ Verification API ได้อีกต่อไป คำขอเหล่านี้จะได้รับกลับมาเป็น:
แอป first-party รวมถึง Account Center และ Console ไม่ได้รับผลกระทบ
การตรวจสอบจะล้มเหลวหาก client identifier ไม่ถูกต้อง รวมถึงแอปที่ถูกลบแต่ access token ยังใช้งานอยู่และ CIMD client ที่ identifier เป็น metadata URL
ไม่มีเส้นทางอ่าน (read route) ใดที่ถูกป้องกันโดยตรงใหม่ อย่างไรก็ตาม เส้นทางอ่านต่อไปนี้ต้องการ record ยืนยันที่ถูกสร้างผ่าน route ที่ได้รับการป้องกันและ third-party จะเข้าถึงไม่ได้อีก
GET /api/my-account/grantsGET /api/my-account/sessionsGET /api/my-account/mfa-verifications/backup-codesการออกโทเค็นและการดึงข้อมูลผู้ใช้จะปฏิเสธผู้ใช้ที่ถูกระงับด้วย invalid_grant เหมือนกับพฤติกรรมเดิมของการลบผู้ใช้
ครอบคลุมถึง refresh token, authorization code, device code, และ token exchange ทุกกรณี แม้จะมีโทเค็นหรือ session ก่อนหน้าที่ยังไม่ได้ถูกเพิกถอนสำเร็จ
การลบ scope ผู้ใช้ออกจากการตั้งค่าข้อตกลงของแอป third-party จะมีผลกับ grant ที่มีอยู่และคำขออนุญาตใหม่
invalid_scope เมื่อเหมาะสมinsufficient_scope หลังจากลบ organizations scope ออกตัวนับ lockout sentinel จะใช้รูปแบบตัวระบุเดียวกับที่ใช้ในการค้นหาบัญชี:
ป้องกันการสะกดหลายแบบของตัวระบุเดียวกันไม่ให้สร้าง bucket การพยายามหลายอันและทำให้ maxAttempts อ่อนลง
การปลดล็อกด้วยตนเองจะล้างตัวสะกดที่เทียบเท่ากันด้วย หลังอัปเกรด lockout เดิมที่บันทึกไว้ในตัวสะกดไม่ตรงรูปแบบอาจหมดอายุเร็วขึ้น แต่ไม่มีผู้ใช้ใดถูกล็อกมากขึ้นกว่าเดิม
redirect_to ใน social landing page ต้องใช้ http หรือ httpsES256, P-384 ใช้ ES384, และ P-521 ใช้ ES512invalid_scope และ insufficient_scope ตอนนี้แสดง scope ที่ถูกปฏิเสธแทนที่จะเป็นข้อความ {{error_description}} หรือ {{scope}} ดิบ ๆAccept-Language ที่มีช่องว่างเช่น en; q=0.7 ตอนนี้ถูกแปลถูกต้องแล้ว ค่าที่ไม่ถูกต้องจะ fallback อย่างปลอดภัยแทนที่จะเป็น NaNgmail.com และ googlemail.com เทียบเท่ากัน และละเว้นจุดในส่วน local partcustom_profile_fields.entity_not_exists_with_namesPOST /applications/:applicationId/user-consent-scopesPOST /organizations/:id/users/:userId/rolesWebhook POST จะ retry สูงสุด 3 ครั้งเมื่อปลายทาง return HTTP 5xx ตามที่ระบุไว้ในสัญญาการส่ง event
ด้วยเหตุนี้ event ที่ retry อาจถูกส่งซ้ำมากกว่าหนึ่งครั้ง ฝั่ง webhook receiver ควรประมวลผล event แบบ idempotent
ตัวเชื่อมต่อ Microsoft Azure AD ตอนนี้รองรับตัวเลือก disableEmailSync
ตามค่าเริ่มต้น ตัวเชื่อมต่อจะคัดลอก mail attribute จาก Microsoft Graph ไปยัง Logto user profile เปิดตัวเลือกนี้เมื่อต้องการยืนยันตัวตนผู้ใช้โดยไม่ซิงค์อีเมลนี้ สอดคล้องกับตัวเลือกสำหรับ Azure OIDC SSO องค์กร
Action required — outbound request protection: หาก webhook หรือ SSO connector เชื่อมต่อบริการบน private network โดยตรง ต้องเพิ่ม IP หรือ CIDR ที่ต้องการใน SSRF_ALLOWED_ADDRESSES ก่อนอัปเกรด:
Allowlist เฉพาะปลายทางที่จำเป็นดีกว่าปิดการป้องกันทั้งหมด
ความเข้ากันได้แบบ dynamic app: ตั้งค่า SSRF_ALLOWED_ADDRESSES จะปิดการทำงานของ CIMD ทำให้ dynamic client ที่ไม่ยืนยันตัวตนไม่สามารถใช้ allowlist เพื่อเข้าถึง private service ได้ การตั้ง SSRF_PROTECTION_DISABLED=true จะปิด CIMD ด้วยเช่นกัน
ความเข้ากันได้ของการตั้งค่า: OIDC_PROVIDER_SSRF_PROTECTION_DISABLED ยังคงรองรับเป็น alias ของ SSRF_PROTECTION_DISABLED ตัวแปรเหล่านี้ใช้กับ self-hosted เท่านั้น
ขีดจำกัด runtime ของสคริปต์: สคริปต์ Custom JWT และ Actions ต้องเสร็จใน 5 วินาที ใช้หน่วยความจำไม่เกิน 128 MB และคืนค่าได้เป็น JSON เท่านั้น
ต้อง migration ฐานข้อมูล: รุ่นนี้มี schema และ index ใหม่ หลังอัปเกรดให้รันคำสั่ง alteration ฐานข้อมูล (npm run alteration deploy ในภาพ @logto/cli/core หรือ logto db alteration deploy) ก่อนเริ่มใช้งานเวอร์ชั่นใหม่ ดู คู่มืออัปเกรด
ขอขอบคุณสมาชิกคอมมูนิตี้ทุกท่านที่มีส่วนร่วมในรุ่นนี้:
ดูรายการการเปลี่ยนแปลงทั้งหมดได้ที่ changelog แบบเต็ม
มีคำถามหรือเสนอแนะ? เข้าร่วมพูดคุยกับเราได้ที่ Discord หรือเปิด issue ที่ GitHub