ซิงค์เซสชันหลายแท็บใน PKCE SPA ด้วย okta-auth-js
เจาะลึกการจัดการ Multi-Tab Session Sync ใน PKCE Single Page App ผ่าน okta-auth-js พร้อมวิธีทดสอบและตัวชี้วัดสำคัญ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ทุกแท็บรัน OktaAuth อินสแตนซ์แยกกันแต่แชร์ localStorage ร่วมกัน
- เปิดใช้งาน tokenManager ด้วย storage, syncStorage และ autoRenew
- รีเฟรชโทเค็นทำให้เซสชันแอปพลิเคชันอายุยืนกว่า SSO ปกติ
- วัดผลความสำเร็จด้วยอัตราการรีเฟรชต่อเซสชันต่อชั่วโมงต้องคงที่
การพัฒนาแอปพลิเคชันประเภท Single Page Application หรือ SPA ที่ใช้งาน PKCE ร่วมกับไลบรารี okta-auth-js มักพบความท้าทายเรื่องการซิงค์ข้อมูลระหว่างแท็บเบราว์เซอร์ โดยแต่ละแท็บจะทำงานด้วยอินสแตนซ์ OktaAuth ของตัวเอง มีตัวจับเวลาและสถานะการยืนยันตัวตนในหน่วยความจำแยกอิสระ แต่กลับใช้ localStorage ร่วมกัน ทำให้โทเค็นกลายเป็นสถานะที่เปลี่ยนแปลงได้ร่วมกัน (Shared Mutable State) โดยไม่มีขอบเขตธุรกรรม (Transaction Boundary)
เมื่อนักพัฒนาทำการกำหนดค่า tokenManager เป็นรูปแบบ { storage: localStorage, syncStorage: true, autoRenew: true } จะมีพฤติกรรมสำคัญสองประการที่ควรทราบ ได้แก่ สถานะ authState จะเป็นค่า null บนหน้า redirect callback เนื่องจาก SDK ตั้งใจข้ามการอัปเดตสถานะในหน้านั้น และการเขียนข้อมูลในเอกสารเดียวกันจะไม่ส่ง event ของ storage ออกมา ทำให้อินสแตนซ์ SDK สองตัวในแท็บเดียวกันไม่สามารถมองเห็นกันและกันได้
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ผลลัพธ์ที่นักพัฒนาต้องตัดสินใจอย่างรอบคอบคือ เมื่อมีการใช้งานรีเฟรชโทเค็น กระบวนการต่ออายุจะหยุดการติดต่อกับ IdP โดยตรง ส่งผลให้เซสชันของแอปพลิเคชันมีอายุยืนยาวกว่าเซสชัน SSO นอกจากนี้ การเปิดใช้สิทธิ์รีเฟรชจะส่งผลกับการเข้าสู่ระบบใหม่เท่านั้น ส่วนเซสชันที่มีอยู่เดิมจะทำการต่ออายุด้วยสคูปร, (scopes) ที่มีอยู่บนโทเค็นเดิม
ในเชิงสถาปัตยกรรมซอฟต์แวร์ การจัดการสถานะข้ามแท็บเบราว์เซอร์ (Cross-Tab State Management) มักเผชิญปัญหา Race Condition เสมอเมื่อใช้ localStorage เป็นสื่อกลาง การเข้าใจกลไกของ Leader Election จึงเป็นหัวใจสำคัญในการป้องกันไม่ให้แต่ละแท็บพยายามต่ออายุโทเค็นพร้อมกัน ซึ่งจะช่วยประหยัดโควตาการเรียก API และป้องกันข้อผิดพลาดที่อาจเกิดขึ้นกับผู้ใช้งาน
การทดสอบสถานการณ์ที่มีสองแท็บล็อกอินอยู่แล้วมักจะผ่านเกณฑ์เกือบตลอดเวลาและไม่ได้พิสูจน์อะไรมากนัก นักพัฒนาควรเปลี่ยนมาทำการทดสอบด้วยแนวทางเหล่านี้แทน:
- บันทึกสถานะผู้นำ/ผู้ตาม (Leader/Follower) และเวลาการรอคล็อก (Lock Wait Time)
- เปรียบเทียบค่า iat ของโทเค็น ณ จุดที่ใช้งานกับ iat ที่เก็บอยู่ในหน่วยความจำ
- นับจำนวนครั้งของคำขอ
POST /tokenในแต่ละรอบการต่ออายุ - ตรวจสอบสถานะ
document.visibilityStateเมื่อเกิดข้อผิดพลาด
มีตัวชี้วัดหนึ่งตัวที่มีค่าควรแก่การสร้างแดชบอร์ดติดตามคือ จำนวนรอบการต่ออายุต่อเซสชันต่อชั่วโมง (Renewals per session per hour) ซึ่งควรจะมีค่าคงที่เสมอไม่ว่าจำนวนแท็บเบราว์เซอร์จะเพิ่มขึ้นเท่าใด หากอัตรานี้เพิ่มขึ้นตามจำนวนแท็บ นั่นหมายความว่ากลไกการเลือกผู้นำ (Leader Election) กำลังทำงานผิดปกติ
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น